che
che copied to clipboard
eclipse-che
An admin should be able to specify secrets or config maps that need to be provisioned on each user's namespace
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: che-secret
annotations:
.....
labels:
.....
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: workspace-secret
type: Opaque
data:
....
apiVersion: v1
kind: ConfigMap
metadata:
name: che-configmap
annotations:
.....
labels:
.....
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: workspace-configmap
type: Opaque
data:
Original labels and annotations should be preserved.
Describe alternatives you've considered
No response
Additional context
https://issues.redhat.com/browse/CRW-2120
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. https://github.com/devfile/devworkspace-operator/pull/417 and https://github.com/devfile/devworkspace-operator/pull/564
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 ?
@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.
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.
@tolusha @l0rd please consider taking this issue to the next sprint for Team A
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:
(...)
@l0rd The side effect of syncing PVC is that we will have one extra PV created on the cluster. Is it ok for us?
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 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).
@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?
@tolusha yes, I belive we should remove the resource from the users' namespaces