[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [che-dev] Add metadata.namespace to Devfile
|
"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.
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
