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
Le jeudi 07 novembre 2019 à 10:32 +0100, Lukas Krejci a écrit :
On 07. 11. 19 10:06, Thomas Mäder wrote:


Hi Lukas,

On 06/11/2019 15:16, Lukas Krejci wrote:


WDYT? Do you have some concerns about this idea?



Yes, I have some concerns: besides creating a "read-only" field in the
devfile (which Mykola mentioned in his answer), I think it would violate
containment: a devfile +/- creates a pod. A pod is container within a
namespace. If we give the devfile control over things which live "up the
hierarchy" from itself. 



If you specify a metadata.namespace field a pod YAML, it will be created
in the specified namespace.

So it you follow the same semantic, when the devfile becomes a K8S custom resource in itself, then
the devfile namespace field will drive where the devfile resource itself will be stored, not the related
workspace pod.


What happens if the user does not have a namespace with the name the devfile 
requests?



As described in my email - if not specified, the namespace is determined
by the che server using the rules we already have in place. Namespace is
an optional field, as it is in k8s.




A devfile should be reusable by multiple people across che installation.
Since the namespaces depend on the configuration of the che instance, a
devfile should not depend on a particular configuration. I think we
should be wary of treating devfiles like stateful objects: devfiles are
portable descriptions of workspaces, not the workspaces themselves. They
are "constructors" if you will, not instances.




I agree with that and I see a lot of good points in Mykola's email. But
at the same time I believe our goal is for the devfile to become a k8s
CR. At that point in time it IS going to have normal metadata section
like every other k8s object and that section WILL include the namespace,
because that is standard kubernetes.

As I tried to explain in more details in a distinct answer, when the devfile becomes a K8S CR
(it is already part of a K8S CR in the Workspace CRD POC), the metadata.namespace field will
switch the a distinct semantic which will be the exact K8S one.

Having the same field with 2 distinct possible semantics according to the context seems odd,
even if the semantics are somewhat similar. 

The namespace is optional for exactly the reasons you describe.



I am not familiar enough with our workspace engine to really pin this
down, but I have a bad feeling about this. Maybe it helps if you explain
the use cases we're trying to cover with this change.




The idea came to our minds, because we are implementing "overrides" that
you could supply to a factory along with a url to a devfile. Factory
would then "materialize" the devfile and apply the overrides. At the
same time, we're adding the ability for the user to specify a namespace
where workspace should be created. It seemed logical and consistent with
Kubernetes to actually kinda "merge" these two features by having the
namespace in the devfile.



/Thomas





_______________________________________________
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

--

David Festal

Principal Software Engineer, DevTools

Red Hat France

Back to the top