Che should have a mechanism to inform user on removed/deleted plugins

[amisevsk]

Is your enhancement related to a problem? Please describe.

Currently, the Che plugin registry hosts every plugin and version published since its inception. However, in the future, we may want to be able to remove plugins from later releases without obtusely breaking old workspaces (e.g. eclipse-che/che-plugin-registry#264).

Describe the solution you'd like

The plugin registry and Che server should be able to surface when a previously existing plugin has been removed from the registry. E.g. the plugin registry could, instead of responding 404 as though the plugin never existed, report info to the user with a possible path to fixing the problem. For old versions (e.g. the rc versions of che-theia), a message could be returned suggesting a move to a new version in their devfile. For completely deprecated plugins such as node-debug, it could at least explain why support was dropped.

Describe alternatives you've considered

With the current approach, removal of any plugin from the registry means the potential for non-startable workspaces when updating Che.

[l0rd]

This looks complicated for an issue that should happen seldom. It should not be a common case because in the devfile registry we always reference latest of plugins and we rarely remove a full plugin.

So an alternative approach would be:

1. We agree that we are going to deprecate plugin X
2. We remove any reference to plugin X in the devfile registry => sprint Y
3. We remove the plugin from the plugin-registry => sprint Y+3

[nickboldt]

1. for node-debug, done. [plugin registry] Do not reference marketplace.visualstudio.com in plugin registry meta.yaml #14573 (comment)
2. there are no refs to node-debug in the devfile registry in 7.3.x, 7.0.x, or master branch.
3. therefore we can remove node-debug from the plugin registry any time after 7.3.x.

[nickboldt]

What do we think about removing old plugins so we don't have to fetch 100s of old SHAs ?

Running the write_image_digests.sh script for che plugin registry today processes 84 containers.

If we remove anything older than 7.3.3, that drops to 67.

Or maybe we want to use LATEST_ONLY arg in Dockerfile to only generate digests for the latest images?

[amisevsk]

I'm 👍 on removing old versions, though I don't know that it's my decision. For only getting digests for the newest images, I'm not sure; it kind of defeats the point of using digests for everything. OTOH it would be a quicker build, so there's that.

Already, latest_only should do what you mean though; if LATEST_ONLY=true, the first step is to remove all older versions, so the SHA checking should be faster already.

[nickboldt]

Yeah after submitting this I found the keep_only_latest.sh so I could use that in CRW if we want downstream.

I'm just looking at not carrying along year-old unsupported garbage in upstream.

[ericwill]

A cull of old plugins in the plugin registry is definitely warranted. 👍

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

[ericwill]

Not really a problem any more since we are only keeping the latest plugin anyway.