Che: Allow users to define workspace deployment labels

[skabashnyuk]

Is your task related to a problem? Please describe.

Eclipse Che workspace can be run in Kubernetes with additional cloud software like istio.
It might be useful to allow users to define custom workspace deployment labels.
These labels can be used by that cloud software to manipulate with trafik of applications that are running inside of the workspace.

Describe the solution you'd like

For example in this way

apiVersion: 1.0.0
metadata:
  name: petclinic-dev-environment
projects:
  - name: petclinic
    source:
      type: git
      location: 'https://github.com/che-samples/web-java-spring-petclinic.git'
attributes:
   workspaceDeploymentLabels: ike.target=preference-v1,ike.session=test

Describe alternatives you've considered

ConfigMap with labels in workspace's namespace

apiVersion: v1
kind: ConfigMap
metadata:
  name: workspace-labels
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-deployment-labels
  annotations:
    che.eclipse.org/automount-workspace-deployment-labels: 'true'
data:
  ike.target: preference-v1
  ike.session: test

Additional context

n/a

[sleshchenko]

Seems to be something that also needs to be addressed in devfile 2.x.
cc @davidfestal @l0rd

[l0rd]

I am not a big fan of the first option: devfiles live in a git repository and it does NOT make sense to store ike target and session in a git repo. These are runtime properties. They can be specified in a DevWorkspace object but should NOT be part of the DevWorkspaceTemplate (i.e. a devfile).

The second option though would require the startup of a "labelled" workspace as 2 steps operation:

1. Create the CM that specifies the deployment labels
2. Call the che server api to start a workspace

This is an acceptable compromise IMO and in a DevWorkspace world the 2 operations can be squashed into one.

[skabashnyuk]

WDYT about adding annotation che.eclipse.org/workspace-name: my-ws instead of che.eclipse.org/automount-workspace-deployment-labels: 'true'

apiVersion: v1
kind: ConfigMap
metadata:
  name: workspace-labels
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-deployment-labels
  annotations:
    che.eclipse.org/workspace-name: my-ws
data:
  ike.target: preference-v1
  ike.session: test

[l0rd]

@skabashnyuk thinking again about that using a configmap to set some deployment labels looks weird.

What about using a factory link parameter:

https://<che-host>/f?url=<devfile-url>&workspaceDeploymentLabels=ike.target%3A%20preference-v1%2Cike.session%3A%20test&workspaceDeploymentAnnotations=ike.target%3A%20preference-v1%2Cike.session%3A%20test

[skabashnyuk]

@l0rd it is more about workspace definition (devfile). We need to put workspaceDeploymentAnnotations somewhere in the workspace.

apiVersion: 1.0.0
metadata:
  name: petclinic-dev-environment
projects:
  - name: petclinic
    source:
      type: git
      location: 'https://github.com/che-samples/web-java-spring-petclinic.git'
attributes:
   workspaceDeploymentAnnotations: ike.target=preference-v1,ike.session=test

[l0rd]

@l0rd it is more about workspace definition (devfile). We need to put workspaceDeploymentAnnotations somewhere in the workspace.

I don't think that we should consider those as part of the workspace definition. These are annotations added by the "debugger" (ike) at runtime (c.f. https://www.youtube.com/watch?v=XTNVadUzMCc&feature=youtu.be).

[skabashnyuk]

ok. Let's imagine it would be a part of Workspace.attributes. How do see workspaceDeploymentAnnotations would be used?

• Created by the factory?
• Can the user adjust them in the existed workspace? How?
• Can the user delete them in the existed workspace? How?

[l0rd]

The user should not adjust them. Those annotations are set by the client that starts the workspace (it can be ike or the OpenShift dev console) and should not be exposed to the user.

[skabashnyuk]

So it's set once(by the factory) for all workspace lifetime?

[l0rd]

So it's set once(by the factory) for all workspace lifetime?

Yes this is correct. @aslakknutsen please confirm.

[aslakknutsen]

In the current line of thinking, yes, that is correct.

There is a certain limitation in relaunching the Workspace to route a new service if you're dealing with a mono repo or similar. Still, I think this is ok for now, so many other unknowns at the moment with some alternative solution.

[skabashnyuk]

@l0rd is there a reason why you used here https://github.com/eclipse/che/issues/18027#issuecomment-703901901 workspaceDeploymentAnnotations and not workspaceDeploymentLabels ?

[l0rd]

@l0rd is there a reason why you used here #18027 (comment) workspaceDeploymentAnnotations and not workspaceDeploymentLabels ?

@skabashnyuk yes because I think that @aslakknutsen mentioned that annotations would be better than labels. In general I think we should be able to set both.

[skabashnyuk]

@aslakknutsen @bartoszmajsak is that possible that you can base your logic on pod labels and annotation instead of deployment. How hard it would be to change for you?. In our case, it's a bit simple to add these labels/annotations to pods in comparison to deployments.

[aslakknutsen]

@skabashnyuk I'll assume when you say annotations on Pods that they will still be defined in the Deployment spec, so we're talking about the difference between deployment.meta.annotations vs deployment.spec.template.meta.annotations? If so, that's fine with us as we can still read them from the Deployment. Our main goal is to transfer some metadata from 'UI' to us via Che essentially. How isn't that important. When we place them on a Pod level we do open up the chance for a Workspace to launch multiple Workspace pods in a single Deployment with multiple 'targets' and by that get multiple routes to it (assuming che supported something like that)

[skabashnyuk]

@aslakknutsen you may ignore my question https://github.com/eclipse/che/issues/18027#issuecomment-707658945 We found an easy way how to set labels/annotations on workspace deployment.meta.