| Re: [che-dev] Add metadata.namespace to Devfile |
That's a good discussion.A devfile is a file format. It's main use case is to be shared (on a git repo for example) and used on different k8s clusters. Infra specific infos should not live in a devfile (like a namespace for example). The same for tatus specific info (like isStopped) or user specific information (like the securitycontext).The workspace CRD is the spec of a k8s API and as such requires some user/infra/status specific information: namespace, security context, stopped/started etc...We have said in the past that we would like to do `kubectl apply -f devfile.yaml` to start a workspace. I think that's source of confusion. A devfile.yaml doesn't have all the informations required by the k8s API and we should not change that if we want it to be portable and easy to read._______________________________________________On Thu, Nov 7, 2019 at 11:07 AM Stevan LeMeur <slemeur@xxxxxxxxxx> wrote:"Devfile is describing what the workspace should be comprised of but doesn't define the workspace itself."Definitely +1 on this.It's very important to keep the devfile as a "spec" for the workspace (and not the workspace itself) as well as not making it "Che specific", so that it can be leveraged by other tools.On Thu, Nov 7, 2019 at 10:54 AM Lukas Krejci <lkrejci@xxxxxxxxxx> wrote:Hi Mykola,
thanks for this, it gave me a lot of things to think about.
The editability of devfile is definitely a concern that we should have
in mind and I agree with you that having a read-only field is weird.
This brought me to an idea, that is actually already realized in the
prototype of the workspace CRD - devfile is not an actual kubernetes
object there, but only a "spec" section of the Workspace CR. And that CR
has the metadata, spec and status fields as usual.
That approach fits into your picture much more nicely (barring the fact
that we already have metadata.name and metadata.generateName in the
devfile, which kinda contradicts that approach). Devfile is describing
what the workspace should be comprised of but doesn't define the
workspace itself.
I think David's reply raises further valid concerns that are essentially
in line with your understanding of devfile as a recipe/spec as opposed
to the actual representation of a workspace.
On 07. 11. 19 9:28, Mykola Morhun wrote:
> 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
>>
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
--Stévan LeMeur // Product Manager // Developer Tools // +336-87-11-27-55_______________________________________________
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
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