Thanks Lukas for sharing this proposal,
Please see my comments below.
Le mercredi 06 novembre 2019 à 15:16 +0100, Lukas Krejci a écrit :
Hi all,
We're adding the ability to specify the namespace in which a workspace
should be created and we are thinking where is the best place to put it.
Kubernetes objects have a optional "metadata.namespace" field, that
defaults to "default" or whatever is supplied as -n to kubectl.
Yes, and this field defines in which kubernetes namespace the current K8S resource will be created
This led us to the idea that devfile, too, should have such a field with
very similar semantics:
To me it seems that these are *not* the exact same semantics. In your case, the `namespace` field in the devfile will
define where *distinct related resources* (the workspace deployment) will be created, and not the current resource (since for now devfile is not
a K8S resource in itself).
But, since we try to define it with a K8S-compatible syntax, imagine that you would apply the same devfile as a K8S custom resource,
then the `namespace` field would define in which namespace the *devfile resource itself* should be added, and not the workspace deployment possibly
created from this devfile.
So we can see that the semantic of this field, and the resulting behavior that it drives, differs according to the context in which the devfile is used
(as a che server internal model or as K8S custom resource).
What do we gain at using, in the devfile, K8S fields with a semantic similar to the K8S one, but not exactly the same ?
Same K8S-like syntax but with slightly different semantics doesn't make the devfile K8S-compatible.
It seems to me that this could even make it harder to use devfiles as real K8S resources in the future.
* optional with the default determined by the Che server (using ourù
config vars for specifying the namespace)
* non-editable
This has some nice consequences:
* it would bring devfile yet another tiny bit closer to other k8s objects
Please refer to my previous remark: what is the value of k8s syntax without exact k8s semantics ?
* because namespace would become part of the devfile model, it would be
consistent with all other devfile value overrides I asked about in my
previous email
(https://www.eclipse.org/lists/che-dev/msg03420.html).
Not having the namespace in the devfile model would require special
handling of the namespace in our REST API - both in factory and the
workspace APIs, which seems a little bit ugly compared to "just override
it as any other devfile attribute".
Initially a devfile was describing the structure and content of a workspace,
not the workspace runtime itself, not the context in which the workspace should be initialized.
Hundreds of workspaces, for hundreds of distinct users in hundreds of distinct namespaces, may have the same structure.
They would have the same devfile that defines the same commands, projects, components, etc ...
It seems to me that all the fields that define how the workspace should be started:
- factory policy: (per-user, etc ...)
- namespace
- ...
should not be stored in devfile fields, because they defined how the workspace will be instanciated, and not what its internal structure is.
Or, if adding a distinct model (and object in the REST API) for those fields makes it too complicated on the Che server side,
I'd prefer adding those fields as *optional K8S annotations* on the devfile.
Isn't it precisely the way annotations are used in K8S ?
> to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata.
As soon as the semantinc of a field is specific to an external (non-K8S) tool that will leverage it, it seems to me that it should
go in annotations whose key is prefixed by the name of the application.
That would give something like the following:
metadata:
annotations:
org.eclipse.che.server.factory.namespace: <theNamespace>
org.eclipse.che.server.factory.creationPolicy: perUser
Going this way would allow keeping the devfile as a real K8S custom resource, while allowing the Che server
to use it to store Che-specific information in it, in order to make its use in the Che context easier.
## Additional details about the devfile seen as a real K8S custom resource
As soon as you want to make a workspace a K8S custom resource, you just realize that a workpace is:
- a workspace structure == devfile, which can be either embedded or just referenced if it exists as a distinct K8S CR
and
- a runtime status
- a namespace where it lives
- and creator that probably created it
- a name (that would be different for each workspace, and also different from the devfile CR name)
You can see here that, if you want to create the Workspace deployment in a given namespace, you would
set the namespace metadata field on the Workspace custom resource, not on the devfile custom resource, that can be referred to from many
workspace objects.
WDYT? Do you have some concerns about this idea? Do you have some
alternative proposals that would make workspace namespace nicely
integrated into our APIs?
For those concerned about the possible security issues (like for example
trying to submit a malicious devfile into kube-system namespace), the
ability to specify a user-defined namespace can be switched off
completely in the che server and our service account can be configured
with limited ability to deploy stuff in certain namespaces.
Thanks,
Lukas
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
