Expose devfile endpoints on subdomains in single-host mode

[skabashnyuk]

Is your task related to a problem? Please describe.

When we were working with a single host we faced quite strict requirements for the content that is served by endpoints. https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-workspace-exposure-strategies/#_single_host_strategy
that become complicated or even impossible to follow for user application see. #17783

Describe the solution you'd like

We would like to change the way how we exposing ports in single-host mode.

• all endpoints defined in devfiles will have a separate subdomain route
• all endpoints from the component in registries that is not marked with a special flag are going to be exposed with gateway as a subpath of the same host.

Describe alternatives you've considered

N/A

Additional context

N/A

[sparkoo]

we should do a quick POC to test how che-theia behaves with preview view with untrusted cert.

[sparkoo]

opened PR #17928 enables exposing all devfile's public endpoints on subdomains, so user applications that are using absolute paths on web UI will work.

Q:

• it can be enabled/disabled with global configuration option. Should it be enabled by default or do we want to keep current single-host behavior.
• We typically don't have wildcard cert in single-host, so we decided to expose such endpoints on HTTP only. This has limitation that preview can't be loaded in the editor directly, because HTTP can't be loaded from HTTPS pages, so users has to open it in separate tab. Is it ok like this at this stage?

cc: @l0rd

[l0rd]

Should it be enabled by default or do we want to keep current single-host behavior

I would say that the default should be che.infra.kubernetes.singlehost.workspace.devfile_endpoint_exposure=multi-host. That's because otherwise our samples and users application may get broken.

so we decided to expose such endpoints on HTTP only

Even if attributes.protocol=https? Otherwise I am ok with it. For the limitation on theia preview panel I think that's a separate issue on for area/editors/theia: if we know that an application won't render decently on the preview panel we should open it on a separate tab instead. Could you please open a separate issue?

[sparkoo]

Even if attributes.protocol=https? Otherwise I am ok with it. For the limitation on theia preview panel I think that's a separate issue on for area/editors/theia: if we know that an application won't render decently on the preview panel we should open it on a separate tab instead. Could you please open a separate issue?

In that case, it's really on https, but it's not usable because the lack of certificate for the subdomain. There is not even "accept the risk" button in editor preview (I guess some browser security feature). You have to again open it in new tab, "accept the risk" there, then you can actually load it in editor preview.

I'll create a new issue to improve the UX for this. Thanks!

[sparkoo]

I've created the editor UX issue #18002