search

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.95k stars 1.19k forks source link

Deprecate installation of upstream Che using the OperatorHub #19659

Closed l0rd closed 1 month ago

l0rd commented 3 years ago

Is your enhancement related to a problem? Please describe.

On any given OpenShift cluster there are 2 Che based operators:

image

That has some problems:

We could argue that on Kubernetes distribution that are not OpenShift the Operator Hub will only have Che. Ok except that from chectl telemtry data we are observing that the Operator Hub is only used on OpenShift.

We could also argue that an OpenShift user may want Che instead of CRW to get the latest features or to use the community (non Red Hat) stacks and Che-Theia plugins. But we (Red Hat) are starting releasing nightly builds of CRW (based on Che main branch) and adding community devfiles to CRW builds.

Describe the solution you'd like

Deprecate Che on Operator Hub.

Update the Helm chart to deploy Che operator on any flovor of Kubernetes (the legacy helm chart should not be supported anymore).

chectl shoudl allow to deploy nightly CRW on OpenShift (OLM) and the Helm chart on the rest.

mmorhun commented 3 years ago

Hello @l0rd I have a few concerns/questions regarding this epic:

  1. Installation

We could argue that on Kubernetes distribution that are not OpenShift the Operator Hub will only have Che. Ok except that from chectl telemtry data we are observing that the Operator Hub is only used on OpenShift.

I think we have such telemetry data because Che is not that popular right now. In general, I believe, people use Operator Hub on plain Kubernetes. It is easy to install it in the end. And possibility to install Che in a few clicks would be a benefit for the project.

Second question regarding this point is OKD.

We could also argue that an OpenShift user may want Che instead of CRW

OKD is more Openshift than Kubernetes, but lacks CRW and if we gonna remove Che from Operator Hub it will be missing there too. So, we'd end up (in better case) in installing Che via Helm on OKD. This brings logical (why don't use preinstalled Operator Hub on OKD) and technical (our Helm chart supposes we are on Kubernetes, otherwise we have to support both platforms in our charts, which requires more burden) kinds of problems.

For the dev team maintaining 2 operators requires more burden

We'll have to maintain both of them anyway...

  1. Testing and debugging

But we (Red Hat) are starting releasing nightly builds of CRW (based on Che main branch)

This is perfectly fine to test the latest features as a user, but it is not for a developer. Imagine, that we need to test how installation from Operator Hub works after some changes made in Che. Instead of just building Che we'd have to build CRW too! This is far from being developer friendly as building CRW requires (at least) special environment (@nickboldt please correct me if I am wrong here). On the other hand providing CSVs for community Operator Hub is mostly automated and is not that hard.

che-bot commented 2 years ago

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

l0rd commented 1 year ago

@tolusha after discussion with @amisevsk @ibuziuk and @AObuchow we decided that it's time to remove Che from OperatorHub and leave Dev Spaces only. So both upstream Che and DevWorskpace upstream operators would be available through a quay.io CatalogSources and we would not have the problem of upstream Che dependent on downstream DevWorkspace. What do you think? cc @nickboldt

tolusha commented 1 year ago

I don't mind.

ibuziuk commented 1 month ago

for the time being there are no plans to remove Eclipse Che from OperatorHub