Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Add metadata.namespace to Devfile

Hello.
You are working on a nice and useful feature, thanks.
I am not an expert in Kubernetes stuff, but I have some concerns about suggested place of the namespace parameter storing.

First I want to mention that our devfile specification is really good designed (in my opinion). We combine here usage simplicity and power of Kubernetes/Openshift native declarations. So, if a new user comes to Che and wants to create a workspace it is really easy even without Kuberbetes knowledge (especially with hints in editor and auto-completion feature). Most of devfile fields are self-explaining. From the other side, experienced and familiar with Kubernetes concepts users might use full power of Kubernetes native definitions and embed them into components description of devfile, which is also a big plus. But these Kubernetes native definitions are added by experienced users on their demand. So, if a user wants to use this power he/she uses it. If a user prefers simplicity it is ok too. But if we add a Kubernetes namespace attribute into devfile metadata we'll force a user to use Kubernetes native stuff all the time. Even if the namespace attribute could be omitted on workspace creation step it will be present in the devfile after workspace creation as read only parameter, which in some way breaks the beauty of the current devfile definition (and its simplicity).
On the other hand we have all the parts of devfile editable, so a user may change anything (including workspace name in metadata section). So, generally speaking, it is possible to just replace the whole content of a devfile at a time (corner case). But if we add a readonly field it will violate current statement of anything is editable.

To avoid described above possible issues we may have another section, say `initialization`, in devfile specification which is stored (or handled) separately from the main content of devfile.
The section is considered on workspace creation step and will be ignored (or even invalid) for already existed workspaces. However, it would be good to display that readonly info in workspace details on dashboard (I mean it should be readable via API).
What do you think about such approach?

On Wed, Nov 6, 2019 at 4:17 PM Lukas Krejci <lkrejci@xxxxxxxxxx> 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

_______________________________________________
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


--

Mykola Morhun

Software engineer

Red Hat


Back to the top