Using OpenShift.io for che plugin/devfile registry going forward

[amisevsk]

Summary

Currently, Che uses openshift.io for default plugin and devfile registries. This will likely cause issues going forward, as those plugin registries are updated independently from the plugin and devfile registry images. In particular, these registries will likely have to be updated alongside releases of Che in order to maintain compatibility.

We need to define clear expectations on the update schedule for the production registries, and accommodate defaults in Che to work with these expecatations. I think that upstream Che should not use production deployments for SNAPSHOT builds.

Relevant information

Today, we ran into an issue where all Che deployments from the current snapshot version fail to start workspaces. This is because

• Che was updated to use eclipse/che-theia/7.0.0 instead of eclipse/che-theia/7.0.0-next: f50d133#diff-2de0b0a873741f8e0d0879a46f8d5266L651
• The plugin registry was updated to remove eclipse/che-theia/7.0.0-next and replace it with eclipse/che-theia/7.0.0: eclipse-che/che-plugin-registry@191df1e#diff-81a58be1dc1db6f64c386b8e5b5b2057L4
• The registry deployed on che.openshift.io is not automatically updated, so it does not contain eclipse/che-theia/7.0.0

Updating the production registries would mean breaking any workspaces that reference eclipse/che-theia/7.0.0-next directly or use it as a default. Further, since there's a manual update process for production deployments, we can't in general expect nightly releases to be available on production.

[amisevsk]

cc: @l0rd @rhopp @slemeur @nickboldt

[amisevsk]

Opened PR #14267 to point current Che to prod-preview registries, which currently get nightly updates.

[amisevsk]

Additional context from the last time we updated the plugin registry: openshiftio/saas-openshiftio#1323 (comment)

[l0rd]

@amisevsk currently the default is to use local registries (deployed alongside the che-server when using helm or the operator) and not to use osio. But that's not clear reading this issue's description.

Anyway I think using prod-preview is a step forward. Not sure if it will be the definitive solution: hosted che and upstream che stacks and plugins may need to be different at some point.

[rhopp]

Agree... Any nightly-snapshot che instances should use its own-deployed registries. From what I'm aware, only minishift addon installation method doesn't deploy its own registries (do we still want to support that?)

[gorkem]

@l0rd My installation over the weekend with chectl to minishift was using the hosted registries which means it is broken. We need a plan to adjust chectl on minishift.

[ibuziuk]

as I recall previously the plan was:

• have an alternative lightweight OIDC provider Look at Keycloak lightweight alternatives for local development #10998
• deprecate single-user mode (together with minishift addon) Dropping single user support #10996

[l0rd]

@gorkem agreed. I did not understand the problem at first. I think the description/title should be updated because that's a minishift add-on specific issue. Anyway using prod-preview registries is a good workaround but that's not ideal. Other options would be:

• update the minishift addon to deploy the registries (but minishift is close to EOL)
• update the che-operator to support deploying che single user and deprecating the minishift addon once and for all.

[johnmcollier]

Note that Che deployed via ./deploy_che.sh will also use the hosted registries.

[amisevsk]

Part of the reason I opened this issue is that we're still using hosted Che registries as default values in che.properties; any Che deployment that doesn't override those in a configmap or environment variable will hit this same problem.

My plan was to use prod-preview until all supported deployment methods come with a registry, and then set the values in che.properties to NULL. At least in that case, Che will fail to start, rather than failing in a more cryptic way (only some plugins don't work).

[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.

[amisevsk]

This issue is out of date as Che gets deployed with compatible registries by all supported deployment methods.