Changes needed to use upstream Che on che.openshift.io

[l0rd]

Motivations

• Users should be able to deploy upstream Che as it is in any k8s/OpenShift cluster, without extra customizations
• Maintaining 2 codebases (che and rh-che) is time consuming from a dev/test point of view

The goal

Reuse the same codebase for upstream che and rh-che

How are we going to achieve that

We should consider making some changes to the following upstream areas (@ibuziuk please help, I am pretty sure I am forgetting something):

• Deployment: we should not have a dedicated rh-che deployment script/template but be able to reuse upstream one
• Workspaces namespace strategy: current strategies don't fit for che.openshift.io, we will probably need to use a template to specify users namespace (e.g. ${username}-che) - #13488
• Stacks: upstream stacks should be built to run on che.openshift.io (as on any real-world OpenShift cluster) and the have images should include pre-downloaded samples dependencies - #13454
• Multi-cluster support, authentication and GitHub integration: I am adding those areas as well for completeness even if, in upstream, we should already have everything is needed

---

Note 1: This is not a Che 7 GA task and should not be included in current sprints. Let's first evaluate how much work is needed and then prioritize it

Note 2: We should not take into consideration Che 6 legacy components (e.g. stacks) but only Che 7 ones

Note 3: To deploy upstream Che on openshift.io we will need changes on openshift.io platform side as well but this issue is not about those. This issue is about the changes Che side

[ibuziuk]

In order to have a more productive discussion please find a simplified schematic component diagram of che.openshift.io:

Challenges:

• multicluster support:
  • (currently handled by oso-proxy) - https://github.com/fabric8-services/fabric8-oso-proxy
• auth
  • under the hood fabric8-auth https://github.com/fabric8-services/fabric8-auth still using keycloak and there should not be many issues to use keycloak directly. However, fabric8-auth also handles automatic user deprovisioning based on last user login, so it is not clear how deprovisioning is going to be handled if hosted che will not be dependent on fabric8-auth.
• stacks there is already to use che 7 upstream stacks as-with with no customizations - https://github.com/redhat-developer/rh-che/issues/1347
• registration flow / user-provisioning currently, users are provisioned by https://github.com/fabric8-services/fabric8-tenant
• unleash toggle support:
  • we are using toggle for handling specific cases per-user (e.g. edit-rights in che namespace, which is required for CI / CD and testing against dev cluster)
• Telemetry Should potentially be handled by
  • https://github.com/redhat-developer/rh-che/issues/1229
  • https://github.com/eclipse/che/issues/12717

[l0rd]

@ibuziuk good points on telemetry and stacks. I understand the rest as well but this issue is to be able to unify rh-che and upstream Che. It's not about replacing fabric8-proxy or fabric8-auth with some new Che capabilities.

In particular:

• It's not about making Che multi-cluster ready: we should, if needed, do the necessary changes in upstream Che to make it compatible with fabric8-proxy
• It's not about bypassing fabric8-tenant: we should, if needed, do the necessary changes in upstream Che to make compatible with fabric8-auth
• It's not about replacing fabric8-tenant provisioning features
• It's not about replacing unleash toggle

These may be further steps but for now the goal is really to unify upstream che and rh-che. Does that makes sense?

[ibuziuk]

@l0rd this does make sense. So, if I understand it correctly the idea is that che would be deployed on dsaas right from the upstream repo (similar che-plugin-registry is deployed as-is to dsaas via https://github.com/eclipse/che-plugin-registry/tree/master/openshift)

[amisevsk]

I'm not so sure about unifying rh-che (with its openshift.io-specific changes) with the general upstream. For example, making Che support fabric8-oso-proxy means adding code related to our specific use case (the proxy does not follow a standard API). Unless we can make a case that fabric8-proxy is the way to run Che multicluster, it should not be included.

Rh-che has been made to fit into the specific environment we have on openshift.io; while adding these changes to upstream Che may make development easier for those of us working on rh-che, it also adds a fair bit of code that would be entirely irrelevant in the general case.

I don't believe downstream-specific modifications belong in the main Che repo. Che should not privilege our specific deployment requirements over others.

[l0rd]

@amisevsk I agree with you and that's not about altering upstream Che to fit osio but rather:

1. making osio as standard as possible
2. improve upstream Che to work perfectly as it is in a prod k8s environment

Even if this issue is about the second point we need to work on the first point as well.

[ibuziuk]

Areas that would be easy to move:

• [x] che-plugin-bayesian-lang-server https://github.com/redhat-developer/rh-che/pull/1481
  • [x] does not work in che 7 (must be moved to che-plugin-registry) https://github.com/redhat-developer/rh-che/issues/1045
• [x] che-plugin-analytics (aka Woopra support) - does not work in Che 7: https://github.com/redhat-developer/rh-che/pull/1481
  • [x] should be implemented from scratch in a generic way (theia plugin / extention part is almost implemented) https://github.com/redhat-developer/rh-che/issues/1714
  • [x] should be disabled by default in the upstream (or eclipse / google analitics - need to verify)
  • [x] telemetry API and Telemetry plugin should be part of the che/theia
• [ ] fabric8-cdn-support (optinal optimization / can be moved to upstream)
• [x] plugin-product-info - Che 6 specific specified as a GIN module, we can remove it after Che 7 release https://github.com/redhat-developer/rh-che/pull/1481
• [x] Dashboard Customization - https://github.com/eclipse/che/issues/15462

Areas that would be problematic to move to upstream:

• [ ] e2e registration flow (OSIO specific, but could be switched via configuration)
• [ ] fabric8-multi-tenant-manager
  • [ ] usage of OSIO specific DTO like UserCheTenantData
  • [ ] Fabric8AuthServiceClient - GitHub Account linking
  • [ ] Fabric8WorkspaceEnvironmentProvider getting the SA token
  • [ ] GuessedSubject related to SA token usage
  • [ ] unleash toogle usage

[1] https://github.com/redhat-developer/rh-che/blob/master/plugins/fabric8-multi-tenant-manager/src/main/java/com/redhat/che/multitenant/tenantdata/UserCheTenantData.java [2] https://github.com/redhat-developer/rh-che/blob/master/plugins/fabric8-multi-tenant-manager/src/main/java/com/redhat/che/multitenant/Fabric8AuthServiceClient.java [3] https://github.com/redhat-developer/rh-che/blob/master/plugins/fabric8-multi-tenant-manager/src/main/java/com/redhat/che/multitenant/Fabric8WorkspaceEnvironmentProvider.java [4] https://github.com/redhat-developer/rh-che/blob/master/plugins/fabric8-multi-tenant-manager/src/main/java/com/redhat/che/multitenant/GuessedSubject.java

[che-bot]

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.

[ibuziuk]

I believe we can close this issue as won't fix