Extending Volume components to support more features

[amisevsk]

Is your feature request related to a problem? Please describe.

Currently, Volume components in a devfile only support a size field. It would be useful to be able to specify more information about what sort of volume is needed:

• Specify that a volume does not require persistent storage (e.g. can be provisioned as an emptyDir volume) -- such volumes are useful for sharing data between containers
• Specify that a volume should exist already (i.e. don't create a volume from this file) -- this would be useful for specifying e.g. a shared ROX assets volume that can be mounted to multiple workspaces
• Specify an external volume's type (e.g. link to a secret that exists on the cluster; link to a configmap on the cluster) -- this would allow mounting secrets/configmaps that already exist into new workspaces.

Describe the solution you'd like

Introduce additional fields on volume components:

• persistent - whether persistent volume is expected to be available after workspace is stopped (default: true)
• external - defines volume as external to the current workspace (i.e. its lifecycle is separate)
• external.type - type of external volume, e.g. "secret", "configmap", or "storage"
• external.name - name of existing resource on cluster

Something like

spec:
  components:
    - name: my-ephemeral-volume 
      volume:
        persistent: false # Volume my-ephemeral-volume will be mounted as emptyDir

    - name: my-external-volume
      volume:
        external: # Setting fields indicates that this is an external volume
          type: storage
          name: my-pvc
            
    - name: my-existing-secret
      volume:
        external:
          type: secret # or configmap
          name: my-secret

Describe alternatives you've considered

Suggestions are more than welcome

[amisevsk]

cc: @davidfestal @l0rd

[maysunfaisal]

I would also like to add to this issue that, we may need to have secrets for outerloop dockerfile build(build guidance) if we want to push to private registries using build configs or importing from private git repos - https://docs.openshift.com/container-platform/4.6/builds/creating-build-inputs.html

[l0rd]

We currently support injecting secrets as files or environment values in Che. But secrets are not specified in the devfile but using some specific labels and annotations on secrets.

We decided to go along that path because we wanted to decouple the secrets (that we considered users specific config) from the devfile (supposed to be shared across users, teams, companies).