Closed l0rd closed 1 month ago
Hello @l0rd I have a few concerns/questions regarding this epic:
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...
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.
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.
@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
I don't mind.
for the time being there are no plans to remove Eclipse Che from OperatorHub
Is your enhancement related to a problem? Please describe.
On any given OpenShift cluster there are 2 Che based operators:
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.