An admin should be able to specify Secrets, ConfigMaps and PersistentVolumesClaims that need to be provisioned on each user's namespace

[skabashnyuk]

Is your task related to a problem? Please describe

There are multiple usecases.

• Share some application environment variables. JAVA_OPTS, MAVEN_OPTS
• Share password and login for some database in all workspaces
• Etc.

Describe the solution you'd like

Secrets and configmaps with predefined set of labels can be propaged to the user's namespace

apiVersion: v1
kind: Secret
metadata:
  name: <secret-name>

  annotations:
    .....
  labels:
    .....
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspaces-config
type: <type>
data:
  ....

apiVersion: v1
kind: ConfigMap
metadata:
  name: <configmap-name>
  annotations:
    .....
  labels:
    .....
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspaces-config
type: <type>
data:

Original labels and annotations should be preserved.

Additional context

https://issues.redhat.com/browse/CRW-2120

[metlos]

As for the instructions on how to map those secrets/configmaps to the workspaces, we should make sure that the DWO labels/annos are used. E.g. devfile/devworkspace-operator#417 and devfile/devworkspace-operator#564

[metlos]

We need to somehow guarantee the order in which the configmaps/secrets would be applied to the workspace.

Imagine an admin would define a "global" configmap with JAVA_OPTS env variable for all workspaces of all users. It is conceivable that some users might want to redefine that env var to something else. They would do that by defining their own configmap in their namespace and labeling it accordingly.

We need to be able to tell DWO in what order it should apply the configmaps such that the "user settings" can override the "global settings".

What do you think about this, @sleshchenko , @l0rd ?

[l0rd]

@metlos good point. We definitely need to label the target secrets/configmaps as app.kubernetes.io/managed-by: che and app.kubernetes.io/created-by: che-server or something like that.

However I think we can leave the how to merge multiple overlapping secrets/cm out of the scope of this issue.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[l0rd]

/remove-lifecycle stale

[l0rd]

@tolusha this is the issue you are currently working on right?

[tolusha]

This one #21605

[ibuziuk]

/remove-lifecycle stale

[ibuziuk]

@tolusha @l0rd please consider taking this issue to the next sprint for Team A

[l0rd]

che-operator should watch for Secrets/ConfigMaps/PersistentVolumeClaims, with the following labels, in the Che namespace:

  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspaces-config

For example if, a ConfigMap like the following one is in the Che namespace:

kind: ConfigMap
apiVersion: v1
metadata:
  name: dev-env-variables
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspaces-config
  annotations:
    (...)
data:
  (...)

then the following ConfigMap should be created in every user namespace:

kind: ConfigMap
apiVersion: v1
metadata:
  name: dev-env-variables
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspaces-config
    controller.devfile.io/mount-to-devworkspace: "true"
    controller.devfile.io/watch-secret: "true"
  annotations:
    (...)
data:
  (...)

[tolusha]

@l0rd
The side effect of syncing PVC is that we will have one extra PV created on the cluster.
Is it ok for us?

[ibuziuk]

The side effect of syncing PVC is that we will have one extra PV created on the cluster.

will let Mario comment, but I think this should not be a problem since this is how k8s works.

PVC does not automatically create a PV; rather, it either binds to an existing PV or triggers the dynamic provisioning of a new PV based on the specified storage class.

N.B. PV provisioning is dependent on storage class e.g. there are non-dynamic storage classes that would require manual PV creation.

Also, if I remember correctly when PVC does not specify a storageClassName, it will only bind to an existing PV that is not already claimed by another PVC. If there is no matching PV available, the PVC remains pending until a suitable PV is manually created and becomes available.

[l0rd]

@l0rd The side effect of syncing PVC is that we will have one extra PV created on the cluster. Is it ok for us?

Yes, that's fine. That's something that the Che admin should manage (i.e. should check if it's possible to get an extra PV for every developer).

[tolusha]

@ibuziuk
I am wondering what we are supposed to do if admin deleted the configmap/secret/pvc in an operator namespace.
Should we remove all the corresponding objects in users namespace?

[ibuziuk]

@tolusha yes, I belive we should remove the resource from the users' namespaces