Reducing the installation options for Che

[l0rd]

Is your enhancement related to a problem? Please describe.

We currently have multiple options to deploy Che. That's hard to maintain and it doesn't bring value for customers.

Describe the solution you'd like

Platforms	Current Options	New Options (step1)	New Options (step2)
minikube/k8s/microk8s/docker-desktop	helm/olm/operator	operator	operator
openshift 4/crc	helm/olm/operator	olm	none (not supported)
minishift	operator	operator	operator

A few clarifications:

• The goal is to have one installation mode only. That's easier to maintain and simpler for users. The only installation mode would be operator (applying the Kubernetes resources to deploy Che operator CRD and controller without OLM).
• On OpenShift there is the option to install CRW (Red Hat distribution of Che) and that should be the default choice. That's why we want to remove Che support for olm (step 2).
• We want to keeep olm support temporarly (step 1) untlil we have weekly releases of CRW (downstream issue). That's because we want have a rapid validating of OLM installation (nightlies build rather than 6 weeks build cadence of CRW).
• we replace current helm chart with a new one that uses operator templates. We publish the new chart to https://artifacthub.io/ and we setup a gh action to automatically release a new version of the chart at every che release

Installers for k8s platform:

Tasks:

• Remove --installer olm option for k8s platforms #20668
• Introduce a new operator-based Helm chart and publish it on ArtifactHub. Remove chectl helm installer. #20552

Subepic:

• Deprecate installation of upstream Che using the OperatorHub

[l0rd]

@tolusha please create a subtask for step 1 and add it as sprint/next. That includes stop supporting helm charts so it's a big change. We need to deprecate it initially and, if there are no strong push back, disable it after a couple of sprints.

[tolusha]

Helmchart deprecation
#20183

[rhopp]

@l0rd Small nitpick - In your table, shouldn't be minishift moved to the row with minikube/k8s/microk8s/docker-desktop? AFAIK minishift doesn't have OLM capabilities (to satisfy step 1).

[l0rd]

@rhopp thanks. Fixed

[nickboldt]

Setting P1 since this is an item to be done in the next 3 mo.

[gazarenkov]

What is the role of chectl in this context?
I see it mentioned as the area/chectl label but no mentions in the description.
Does the operator option automatically imply using chectl (only?) as a mechanism to perform it?

[l0rd]

chectl sever:deploy is the way to deploy Che using the command line. And it should continue to be like that.

Step 1 implies that we should deprecate the "--installer" parameter because there is only one per platform. Step 2 (blocked by this downstream issue) means that we should deprecate "openshift" and "crc" platforms as those should be better served/covered by CRW. @tolusha does that make sense for you?

[nickboldt]

On OpenShift there is the option to install CRW (Red Hat distribution of Che) and that should be the default choice. That's why we want to remove Che support for olm (step 2).

Does this mean that crwctl will ONLY be used for OCP 3.11 (operator mode) ?

Or is the plan to keep olm mode in crwctl, but remove it from chectl?

Asking because QE relies heavily on crwctl to do install tests w/ CRW 2.13. Seems a strange choice to make crwctl an Officially Supported install method, then remove it a few months later.

So if crwctl will continue support olm mode, we need to be clear about HOW we'll maintain the fork downstream once we get to step 2.

[tolusha]

OCP 3.11: crwctl with --installer operator
OCP 4.x: OpeatorHub + crwctl with --installer olm

[nickboldt]

Ah, so no change then. This is the current state of affairs for CRW:

OCP 3.11: crwctl with --installer operator
OCP 4.x: OpeatorHub + crwctl with --installer olm

[Kasturi1820]

@tolusha Is step 1 done ?

[tolusha]

@Kasturi1820
Yes, completed.
Besides the fact, that it is still possible to use --installer operator to deploy on OpenShift (moslty for testing purpose)

[l0rd]

Closing this issue as the first step is done (reducing the installation options). The second step (remove Che from OperatorHub) is tracked in a distinct issue and is blocked by this downstream issue.