Prepare the DevWorkspaceOperator for Devfile 2.0 support in Che

[davidfestal]

• Use the Devfile 2.0 Specification
  • 1. Validate the new plugin mechanism with a complete devfile that contains only containers components, commands and events (cf. the following gist: https://github.com/davidfestal/api/blob/devfile-2.0-vscode-plugin-management/samples/plugin-sample/all-in-one-theia-nodejs.devworkspace.yaml)
    • Implement the apply of container components on preStart events => create an initContainer Implement apply of container component on preStart events #183
    • Complete the Devfile 2.0 implementation of Endpoints: exposure, protocol , secure, path are not out of attributes Complete endpoints implementations needed for Theia plugins #184
    • Implement the Volume component (or infer it when there is a mount for now ?) Implement Volume component #185
    • Create the VSX installer docker image to be used in the vsx-copier component definition
  • 2. Use the latest devfile/api repo content
    • Update the DevWorkspace Controller to Operator SDK 1.0 (compatible with the new kubebuilder) Update the DevWorkspace Controller to Operator SDK 1.0 #180
    • Include the conversion between v1alpha1 et v1alpha2 dans devfile/api cf https://book.kubebuilder.io/multiversion-tutorial/conversion.html - Implement conversion webhooks for devfile/api versions #189
    • Add conversion-gen calls to generate conversion code for all the parts that are the same
    • Create the conversion webhook based on this code in the DevWorkspace controller
  • 3. Validate the new Devfile 2.0 plugin mechanism
    • Allow inline parents and plugins and implement them in the DevWorkspace controller
    • Implement minimal flattening in case of inline parents / plugins
    • Test devfile 2.0 plugin mechanism with for terminal, Theia editor and one Theia remote plugin - only based on inline elements
    • Evaluate and fix the impacts on Che-theia integration:
      • Get the flattened devfile from the new che-theia workspace client library
      • How do we flag components that come from a plugin, to be able to gather them in the che-theia UI and make the distinction from user-runtime containers ? => Add an optional attribute on a non-plugin components ?
  • 4. Implement full support of Devfile 2.0 plugins
    • Implement complete flattening of parents / plugins, as a dedicated controller on a dedicated custom resource (simply a DevWorkspaceTemplate if we add a DevWorkspaceTemplateSpecContent in its status ?). There should be an option (false by default) to enable the use Devfile 2.0 plugin mechanism for plugins loaded through ID or url.
    • Build a plugin v2.0.0 registry based on Implement a proof of concept OCI registry for devfiles registry-support#2, and fill it with the translation of v1.0.0 plugin into v2.0 plugins
  • 5. Make full support of Devfile 2.0 plugins the default behavior
    • Update the DevWorkspaceController embedded plugin registry to be compatible with the devfile 2.0.0
    • In CheCtl, when deploying with the devworkspace engine, deploy a Devfile 2.0.0 plugin registry. Or setup a conversion mechanism in a plugin/registry, that provides devfile 2.0.0 plugin yamls from the 1.0.0 ones ?
    • Set the default Devfile 2.0.0 plugins option to true by default

(1 // 2) > 3 > 4 > 5

[l0rd]

We should make sure that this issue is taken in consideration eclipse-che/che#17975

[sleshchenko]

Closing since it does not seem to have an actual data. A new plan can be followed with step 2 and step 3 labels.