[devworkspace] Evolving CheCluster CR into the DevWorkspace era

[metlos]

Devworkspace STEP 1 moves Che into an interesting transitional period where it will need to support 3 subsystems, each configured differently, that will somehow need to co-exist and interoperate.

In STEP 2 I think we should strive to unify the way we configure them.

The situation in STEP 1 is following:

1. CheCluster CR - This configures the behavior of the che-server and therefore the behavior when working with Devfile v1. This includes the familiar configuration items like:
   • che server configuration
   • database configuration
   • auth configuration
   • storage configuration
2. Devworkspace Controller ConfigMap - devworkspace-controller reads its configuration from a ConfigMap (with a configurable location) - this includes the following configuration options atm:
   • PVC name
   • PVC storage class (overlap with CheCluster)
   • default routing class
   • routing suffix (e.g. the base domain for the workspace component endpoints exposed on subdomains) (overlap with CheCluster)
   • sidecar pull policy
   • controller webhooks enablement they should be always enabled now
   • workspace idling timeout (overlap with CheCluster (through custom properties)). Note: idling settings on DWO side is used only for WTO currently.
   • workspace controller service account name. Note: is not a good example, it's our internal of webhooks, unless Workspace SA is meant to be here
3. CheManager CR - governs the behavior of the Che aspects of Devworkspace. This is currently quite limited:
   • Singlehost gateway host (overlap with CheCluster)
   • Images used for singlehost gateway (overlap with CheCluster)
   • Status of the che subsystem (resolved gateway host, if not explicitly defined on OpenShift, lifecycle phase)

Having 3 places for configuration is not a good UX, especially given the fact that all 3 of them already have some overlap in STEP 1.

Devworkspace operator needs to function as a standalone component without Che so it needs to have its own way of configuring itself. That said, I think we should strive for an arrangement where, when Devworkspace Che is deployed, both devworkspace operator and devworkspace che operator would use a single(-ish) configuration source.

[l0rd]

cc @tolusha

[metlos]

Let's limit the scope of this issue to just evolving CheCluster CRD. I've created another issue, #19326, to discuss the way we share/cascade the configuration between DWO, DWCO and WTO.

[metlos]

Evolution of CheCluster

Che installation is currently configured through the CheCluster CR which contains explicit configuration for the most common properties of the che server as well as a mechanism to pass lower-level env variables to configure che server.

Devworkspace can currently only be installed through the che-operator if CheCluster enables itusing spec.devworkspace.enable property.

Currently, we support multiple CheCluster instances running in the cluster. We want to drop thatcapability for Devworkspace.

We need a way of configuring both the existing Che7 infrastructure as well as the new Devworkspace infrastructure ideally from a single place.

This assumes that we have merged devworkspace-che-operator into the che-operator, which is something that has not yet been done at the time of writing this but we have a plan to do so.

Below are a couple of strategies that we may choose to support che7 and devworkspace in parallel using a single(-ish) CR.

Add devworkspace config to spec.devworkspace

We could just keep CheCluster as is and configure parts specific to devworkspace in a dedicated map, spec.devworkspace. We already have it because using spec.devworkspace.enable we tell the che-operator to install the devworkspace operators into the cluster. We could just add other properties under this map or even base some elements of devworkspace on existing configuration of CheCluster (like for example locations of plugin registries, etc.).

Disallowing more instances of CheCluster is a matter of checking the cluster state during reconciliation.

Pros:

• simple
• single CR to configure both che7 and devworkspace

Cons:

• doesn't solve how are we going to get rid of che7 props in the future
• keeps the CheCluster name

Create CheCluster v2alpha1 for devworkspace che

We could take advantage of conversion webhooks and start storing a v2alpha1 version of the CheCluster that would have the old che7 configuration stashed under spec.che7 and devworkspace config properties directly under spec. This way, the che operator could have 2 controllers reacting to this new version and one would just read the spec from under che7 and continue normally as we do at the moment and the other would read the dw configuration and apply it to devworkspaces.

Disallowing more instances of CheCluster is a matter of checking the cluster state during reconciliation.

Pros:

• Single source of truth
• Conversion possible
• We can drop support for spec.che7 at some future point in time (with v2) without other code changing.

Cons:

• changes in che-operator required, although minor ones
• we keep the CheCluster name

Create DevWorkspaceCheConfiguration CRD for devworkspace che

This is similar to CheCluster/v2alpha1. We would not be able to use a conversion webhook as we would use another kind of CR but that could be solved by just reconciling a CheCluster by a correspoding change on DevWorkspaceCheConfiguration.

Disallowing more instances of DevworkspaceCheConfiguration is a matter of checking the cluster state during reconciliation.

Pros:

• we move away from the confusing CheCluster name

Cons:

• non-standard solution to conversion

[metlos]

We've settled on using CheCluster v2alpha1 (i.e. the approach number 2). This is tracked separately in #19448 and the aspects of configuration "sharing" between dwco, wto and dwo are also tracked separately in #19326 . Therefore I'm closing this issue.