Automatically mounting volumes, configmaps, and secrets

[kadel]

• Implement specifications at https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets
• Document behaviour (or point to the specification)
• integration tests
• Check with @kadel / @l0rd the new label replacing controller.devfile.io/mount-to-devworkspace
• Only on cluster
• Implement controller.devfile.io/mount-access-mode (Add annotation for setting access mode on automounted configmap/secret files #6728)

related to #6478 epic

[valaparthvi]

@kadel Can you set a priority on this? Also, care to elaborate?

[valaparthvi]

Related to #6542.

[kadel]

Bumping priority as we have a user requiring this to use odo in their environment.

[feloy]

@kadel, What is the purpose of controller.devfile.io/watch-configmap and controller.devfile.io/watch-secret labels? (https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets)

[feloy]

@kadel Do we want to implement this for Podman?

[kadel]

@kadel, What is the purpose of controller.devfile.io/watch-configmap and controller.devfile.io/watch-secret labels? (https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets)

not sure :-(

@kadel Do we want to implement this for Podman?

Not for now. If I'm not mistaken, Secrets and ConfigMaps are not supported on Podman. Once podman adds support for those we should implement this.

Volumes are supported to some extent on Podman, but I don't think it makes sense to do just partial implementation for volumes. We will add all this together with Secrets and ConfigMaps

[feloy]

@kadel What would be the new label replacing controller.devfile.io/mount-to-devworkspace?

[feloy]

@l0rd Do you have an opinion on what should be the new label replacing controller.devfile.io/mount-to-devworkspace to have a label used by all tools?

[l0rd]

@feloy I was thinking about controller.devfile.io/auto-mount but I also like the one that you have in the PR controller.devfile.io/mount-to-containers. @amisevsk @AObuchow what do you think?

[amisevsk]

@kadel, What is the purpose of controller.devfile.io/watch-configmap and controller.devfile.io/watch-secret labels? (https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#automatically-mounting-volumes-configmaps-and-secrets)

These labels are required for the DevWorkspace Operator (and should not be necessary for odo). In operator land, we don't want to cache every configmap/secret on the cluster internally, so we filter by label. Since configmaps/labels aren't associated with any one workspace, we need a more generic label for "relevant to DWO".

I was thinking about controller.devfile.io/auto-mount but I also like the one that you have in the PR controller.devfile.io/mount-to-containers.

If we're moving the label definition up to devfile/api, we should modify the controller.devfile.io part -- that is included to scope labels/annotations to the DevWorkspace Operator (as opposed to the general devfile API). As for specific naming, I like auto-mount as it's shorter, but worry it may be just the language we use for the feature and so confusing to users.

[kadel]

I was the one who originally suggested keeping controller.devfile.io to Mario, I thought that it will make things easier for DWO, as most of the labels could stay as they are.

controller.devfile.io is generic enough that I think we could keep it.
I'm more than fine with using something like devfile.io/... if DWO supports that as well.

[amisevsk]

If we're content with adopting controller.devfile.io, then that works too -- it's up to the collective conscious :). It certainly would be easier for DWO, at least.

My main concern would be long term -- we should decide what prefix/name we want to use for devfile API-defined labels and annotations and stick to that going forward (e.g. controller.devfile.io, devfile.io, etc.). When we started requiring specific labels that the DevWorkspace Operator adheres to, we opted for controller.devfile.io -- this is used for other DWO-specific labels, e.g. controller.devfile.io/restricted-access, controller.devfile.io/storage-type, etc.

[feloy]

Do we all agree to use these?

• label devfile.io/auto-mount
• annotations devfile.io/mount-path, ...

to: @amisevsk @kadel @l0rd

[l0rd]

@feloy apologies for bringing this up last minute but there is another annotation added last week:

controller.devfile.io/mount-access-mode: 0777

[feloy]

@feloy apologies for bringing this up last minute but there is another annotation added last week:

controller.devfile.io/mount-access-mode: 0777

Thanks for the link. we'll implement this in another PR. I have created an issue to track it