Registries should be provisioned with their public URL by default.

[amisevsk]

Is your enhancement related to a problem? Please describe.

There are various open issues around serving e.g. images from the registries themselves rather than using external links: #14844, similar for plugin registry (I can't find the issue at the moment)

To support this in the general case, it would be very convenient if all deployment methods for Che + registries provisioned an environment variable containing the registry's public route or something similar. This is currently done by default when deploying Che in offline mode for the devfile registry to support serving project zips, but would be useful in allowing the registries to serve content in general.

If this functionality was included, it would be very easy to e.g. cache all plugin and devfile icons during build and serve them from the registry by default. Additionally, adding this functionality for the plugin registry is required for supporting plugin icons in offline mode.

Describe alternatives you've considered

The alternative would be to ensure that all consumers of data from the registry can handle relative links (e.g. relative links for devfile icons point at the dashboard, not the devfile registry).

Additional context

This may be possible using the k8s downward API, but I haven't investigated enough.

[ibuziuk]

@amisevsk am I correct that this very issue is not for CRW 2.0 ? also description does not contain info about env vars

[ibuziuk]

not sure which team should handle this task, so putting devex for now

[amisevsk]

@ibuziuk You're correct, this isn't a CRW issue directly. Mostly created for tracking, since it's a prereq for some other issues.

[amisevsk]

This is currently important for offline and airgap deployments, as in that case plugin icons do not work in e.g. the plugin viewer panel of Theia.

cc: @nickboldt

[nickboldt]

Yep, important for CRW 2.1.

Maybe we need a label for "airgap/offline" ? @l0rd WDYT?

[sleshchenko]

The alternative would be to ensure that all consumers of data from the registry can handle relative links (e.g. relative links for devfile icons point at the dashboard, not the devfile registry).

My personal +1 to alternative way =) Why I think it's quite logical:

1. We already do it: I mean we already transform relative links to meta.yaml and devfile.yaml to absolute since index.json contains relative links to files.
   https://che-plugin-registry.openshift.io/v3/plugins/
   https://che-devfile-registry.openshift.io/devfiles/
2. In theory, it allows Registries do not care about host used by clients to reach them, whatever it's public Ingress/Route or internal k8s/OS network - via services.

So, on the one hand, we can simplify clients but make our deployment methods a bit difficult.
So, on another hand, we can keep deployments as now but ask clients to transform relative links to absolute on their own - it's actually what they already do for retrieving meta.yamls and devfile.yamls.

It seems to be a quite common issue and I like the phrase I found but I'm afraid we are not able to implement it currently with Apache Server

Solution is server-side always obtaining that prefix from HTTP request's "Host" header.

[amisevsk]

The issue with relying on all consumers to resolve relative links correctly is that the yaml from the registries is passed around after retrieving it. Examples:

• The dashboard would have to resolve relative links in a manual way before displaying it -- if the devfile icon link is relative, the browser resolves it against the dashboard endpoint, not the plugin registry.
• Once a workspace is created, the devfile is entirely disconnected from the registry it came from. A relative link there doesn't make sense, so it would have to be rewritten before the devfile is saved.
• In a workspace, relative links to e.g. plugin icons would resolve against the workspace endpoint, not the plugin registry, since Theia pulls plugin metas and processes them to display.

This ends up meaning that the alternatives are

1. Make sure registries know their public URL and do the rewriting once, there
2. Make sure everything that handles data from the registries is able to do the rewriting itself, before passing it to the user.

For e.g. the plugins index, we don't actually use the relative links AFAIK. The index is used to display plugins to the user; if a user adds a plugin from there, the devfile gets the plugin's FQN added, which then results in the broker directly requesting it from the registry during brokering.

[davidfestal]

In the context of CRW 2.1 installation on OpenShift 4.3 restricted environments, it seems that we should provision the devfile regsitry with its public URL by default, and not only when one of the airgap Custom Resource field is set (as was done in this commit).
The procedure to install CRW 2.1 on OpenShift 4.3 restricted environments through OLM does not require setting any airgap-specific field in the Custom Resource and currently we end up missing the devfile-registry config map that should define the registry public endpoint.

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