| Re: [che-dev] Add metadata.namespace to Devfile |
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. > 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. 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature