CheCluster CR should not be created in openshift-operators namespace

[l0rd]

Is your enhancement related to a problem? Please describe

Che operands are deployed in openshift-operators namespace. That namespace, as it's name suggests, is dedicated to operators and not to operands. We should not deploy postgres, database, registries, server, dashboard etc...there.

Describe the solution you'd like

CheCluster CR should be created in eclipse-che namespace as soon as the operator is deployed.

That also means that an admin doesn't have to manually create a CheCluster after Che operator subcription: it's automatically created (1 step installation instead of 2 steps installation).

Additional information

OpenShift GitOps operator does that: it creates the openshift-gitops namespace if it doesn't exist and
Red Hat product OpenShift Dev Spaces default CheCluster namespace should be openshift-devspaces.

[ibuziuk]

Red Hat product OpenShift Dev Spaces default CheCluster namespace should be openshift-devspaces

probably we should reconsider the openshift- prefix since it will be impossible to use such namespaces on OSD - (^kube-.|^openshift.|^default$|^redhat-.*)"

[l0rd]

Red Hat product OpenShift Dev Spaces default CheCluster namespace should be openshift-devspaces

probably we should reconsider the openshift- prefix since it will be impossible to use such namespaces on OSD - (^kube-.|^openshift.|^default$|^redhat-.*)"

Yes, I would do what other openshift prefixed products do with their operands (pipelines, service mesh, serverless, gitops, sbo etc...)

[l0rd]

A couple of comments:

1. By default chectl creates the CheCluster CR in eclipse-che, not openshift-operators (dsc should NOT deploy to openshift-operators).

2. OpenShift Pipelines operator automatically creates an ArgoCD Custom Resource in openshift-gitops namespace. So 1) the default is an openshift- prefixed namespace 2) the CR is automatically created in one step (whereas Che requires admins to do that in 2 steps). This should be the example to follow.

cc @dmytro-ndp @nickboldt @Kasturi1820 @RickJWagner

[l0rd]

We have checked with @ibuziuk and, when deployed on OSD, OpenShift GitOps creates a openshift- prefixed namespace. So that's what Che/DevSpaces should do too.

[l0rd]

Downstream issue

[tolusha]

@l0rd
I have some concerns about CheCluster creation by the operator. I do believe it will lead having 2 CR (the first one created by the operator, another one - created by user via OpenShift UI)

So, I'm thinking of a slightly different approach. Let's keep the current behavior but, If user creates CheCluster CR in openshift-operators namespace, then operator moves it to a right place (creates namespace if needed).

WDYT ?

[l0rd]

This is a good point @tolusha.

I would not move a CR created by a user. It would be hard to follow what's going on.

This is how it works for OpenShift Gitops:

1. Click install in OperatorHub

2. Select the "Channel" and the "Update approval"

3. A completion message appears

4. An ArgoCD instance has been created automatically in namespace `openshift-gitops`

5. Users can still click on "View Operator" and create a new "ArgoCD" instance

For me that's easier than what we currently have. But I will review it with @RickJWagner and @Kasturi1820 .

Two ways to make it even better are:

1. Print Che URL in the completion message at step 3
2. Provide an error message if a user tries to create a second CheCluster in the OpenShift cluster similar to this one:

[l0rd]

After discussions I think that there is value in having a 2 steps installations. Keeping things like we currently have allow to split tasks:

• OpenShift admin creates the subscription
• Che admin create the CRD

And it doesn't seem like an issue that some "distracted users" would not change the namespace and create the CR in openshift-operators: this is unlikely in real-world production clusters.

Closing this issue.