| Re: [che-dev] Add metadata.namespace to Devfile |
Thank you everyone for the responses. They gave us (and especially me, personally) much better picture about how we want the devfile to evolve. >From the replies and also the discussions we had in person, the following became apparent. Because devfile as is at the moment will not itself become a kubernetes object, it would be counterproductive to make it look like one (we just need to keep in mind that devfile may become a part of a spec of some kubernetes custom resource and therefore we should keep the schema "kubernetes friendly"). Also, extraneous, infrastructure specific, information doesn't belong into a file that should ideally be vendor or target infrastructure neutral. Therefore, we will not do anything to the devfile schema to support our usecase in the end. We will also separate the specification of the workspace namespace from the devfile overrides because, by the above logic, they are different things (workspace content vs a runtime concern). This is how we are going to go about specifying the namespace for a workspace and devfile overrides: * namespace will be specified as an optional query parameter on the workspace API (and only there). If not specified, the configured default will be used (as it is done at the moment) * overrides to devfile attributes will be specified as query parameters of the factory API (and only there) * to support deploying to a user-defined namespace during the factory flow, we will have to modify the factory flow to ask the user for the target namespace (this has not been planned or approved, but we think it is a reasonable thing to do). This gives us nice separation of concerns (workspace content vs deployment/runtime specifics) and doesn't need to touch the devfile schema at all. Again, thanks everyone for their valuable input! Lukas On 06. 11. 19 15:16, Lukas Krejci wrote: > 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. > > This led us to the idea that devfile, too, should have such a field with > very similar semantics: > > * 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 > * 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". > > 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature