Updates to the Devfile 2 model to support Che workspaces

[l0rd]

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.

[sleshchenko]

This issue is just about model changes and it can be closed I believe.
@amisevsk Could you please provide what is the devfile settings for async storage? Is it going to be the same as we used to have on devfile v1 level to switch all persisted volumes to async

attributes:
  ephemeral: true
  async: true

?

[amisevsk]

The current attributes are confusing, since we initially had ephemeral: true and so had to add async: true on top to keep backward compatibility. Starting over, I think the (probably label, not attribute) should be something like storageType: [common|ephemeral|async], with common being default if undefined.

[l0rd]

The current attributes are confusing, since we initially had ephemeral: true and so had to add async: true on top to keep backward compatibility. Starting over, I think the (probably label, not attribute) should be something like storageType: [common|ephemeral|async], with common being default if undefined.

@amisevsk it makes sense. When you say "label, not attribute" you are thinking of to the DevWorkspace metatdata.labels?

[amisevsk]

When you say "label, not attribute" you are thinking of to the DevWorkspace metatdata.labels?

Yes, for now at least. We may revisit this once devfile/api#352 is merged, since that would add top-level attributes to DevWorkspaces.

[l0rd]

@amisevsk we just added ephemeral: [true|false] as a field of volumes in the devfile spec. Shouldn't we replace that with storageType: [common|ephemeral|async]?

[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.

[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: #19194