Updates to the Devfile 2 model to support Che workspaces

Is your enhancement related to a problem? Please describe.

There are some features of workspaces that could be specified using a Devfile v1 that it’s not possible to specify using Devfile v2 yet.

Describe the solution you’d like

• Support ephemeral controller team

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

• asynchronous storage controller team
• Support secret and configmap injection (to review if we want to support current injection mechanism) controller team ^ we don’t need to have it on devfile model, we’re going to implement it in the same way as currently Che does, match secrets and configmaps with their labels/annotations.

[l0rd]

@amisevsk makes sense. So that would not require a change in the devfile v2 model spec and I am closing this issue then. I have opened an issue for the storageType annotation: https://github.com/eclipse/che/issues/19194

[amisevsk]

@l0rd No, I don’t think so. I view the ephemeral field on volumes as serving a separate purpose – it allows you to share data between containers without requiring persistent storage. The idea would be to have the overall workspace have [common|ephemeral|async] storage, but you can mark individual volumes in the devfile as ephemeral if you just want shared disk between images (a great example of this is the remote runtimes volume, which we want to be ephemeral even in an async/common workspace).

Having a per-volume setting for storageType becomes very tricky, as there could be conflicts (e.g. one volume uses common and one uses async, which would mean mounting the common PV in two places).

For storageType: ephemeral, setting ephemeral: true on volumes would have no effect, but for common/async it’s needed.