Adopt DevWorkspace - a simpler and more lightweight kubernetes-native architecture, and the Devfile v2 specification for increased interoperability

[l0rd]

Is your enhancement related to a problem? Please describe.

When a workspace is defined using the devfile v2 Che should create a DevWorkspace Kubernetes Custom Resource and delegate the creation of the Kubernetes pod and other objects associated to a workspace to the DevWorkspace controller.

This epic is part of #15425

Milestones

milestone 1 - DevFile v2 support COMPLETED

The following features are included in this milestone:

• Deploy Che and the DevWorkspace controller using chectl server:deploy --workspace-engine=dev-workspace
• Support factory link that points to a git repo with a devfile 2.0 (WITHOUT plugins). Theia, machine exec, route class are implicitly added by Che.
• CheTheia doesn’t use Che server API anymore but reads workspace info it needs from DevWorkspace / cluster resources directly
• Dashboard provides the list, status, progress of DevWorkspaces
• Updates to the devfile model to support ephemeral and asynchronous volumes
• Documentation updates to include DevWorkspace engine support
• Setup of the DevWorkspace version of the Happy path e2e test
• Initially supported namespace strategy: per user
• Initially supported PVC strategy: common
• Single host routing supported only
• Workspaces are not authenticated (anyone with the URL has access)
• Not compatible with the Web Terminal operator

milestone 2 - Support for editors plugins and samples stacks COMPLETED

The following features are included in this milestone:

• Che Theia Plugins support
  • In the plugin registry, Che-Theia Plugins definition should be in the Devfile format
  • The Dashboard should be able to get the definition of a theia plugin and create the corresponding DevWorkspaceTemplate
  • The DevWorkspace controller should be able to reconcile a DevWorkspace with a plugin that points to a DevWorkspaceTemplate (PR Plugin flattening devfile/devworkspace-operator#240)
• Devfile registry should include some v2 devfiles
• Che with devfile v2 support run on Kubernetes (minikube)

The following are not:

• Auth for workspaces (whoever guess the URL gets in)
• Support for override vsx extension sidecar (for example run it in theia or in user user containers)
• Use of the new devfile registry (used by odo)
• Parents support
• GitHub/GitLab/BitBucket and private repositories support
• Support for OpenShift 3.11 and 4.4 or lower

milestone 3 - Che server and DevWorkspace engines feature parity

The items below may be outdated. The source of truth are issues in in the endgame plan

• Merge Che-Theia and machine exec
• It should be possible to install Che and OpenShift Web Terminal on the same cluster
• Support trusted certificates bundles
• Support custom TLS certificate for Che ingress
• Support injecting secrets in workspaces (maven settings, ssh keys, git credentials…)
• Theia manages .vscode/extensions.json recommendations files
• Include in Che Dashboard some getting started example with vscode extensions
• Multi-host support
• Ephemeral and asynchronous storage (implementation)
• DevWorkspace operator is published on the OperatorHub
• No devfile use case support
• DevWorkspace devfile parent and other v2 features support
• Che multi cluster support using one DevWorkspace` operator per cluster

This milestone includes those epics:

• Che Theia should detect and apply local devfile changes
• Recommend to include a Devfile in projects that don't have one
• Devfile 2.x support
• Multi cluster support

[sparkoo]

@l0rd do you have any rough plan for how long we will support devfile 1.x and 2.x simultaneously? Will devworkspace ever support 1.x or wsmaster will do 1.x and devworkspace 2.x, until at some point we drop 1.x support?

[skabashnyuk]

@l0rd

@sleshchenko and I would like to take a look from the perspective of the desired architecture in the future. When we do not have any legacy obligation. Because now wsmaster has multiple leftovers from Che 6 and adding devfile 2.0 spec to it will make further support even more difficult. Later we can add some constraints with legacy code support if needed. In other words, we want to make/see the whole transition plan before we start implementation.

[l0rd]

@sparkoo I don't think devworkspace will ever need to support devfile 1.x. I cannot say for how long we will support both, that depends on how fast we will be able to have 1.x main features implemented in the devworkspace controller. At that point we should switch rapidly to 2.x only. Probably that will correspond to the 8.0 release.

@skabashnyuk sure. How do you want to proceed?

[sparkoo]

the devworkspace operator should become a dependency of the che operator

@l0rd will there be different way how to deploy devworkspace operator? Or che-operator will be only supported option?

[l0rd]

@sparkoo the devworkspace operator is a dependency of both che and web terminal operators. Hence it will be deployed when deploying the openshift web terminal as well.

[l0rd]

The DevWorkspace based architecture is the default since Che 7.42 release.