[che-dev] How workspace routing works in devworkspace compared to che7

[Lukas Krejci <lkrejci@xxxxxxxxxx>]

Hi all,

given the recent discussions about what and how we should concentrate on and 
implement in the devworkspaces, I thought it might be good to sum up the 
current thinking (and implementation) about how the routing to the 
devworkspace endpoints should work and compare it with what we have in Che7.

==== CHE 7

In Che7, there are 2 explicit modes for routing the workspace component 
endpoints, called "multihost" and "singlehost".

With multihost every endpoint is exposed through a dedicated ingress.

In singlehost, the situation is more complex. The plugin endpoints are by 
default exposed on subpaths of the che server host, but can opt out of this 
behavior. The endpoints defined in the devfiles are still always exposed on 
subdomains (with no option to change that).

==== DEVWORKSPACE

In devworkspace we have to accommodate for the fact that it is no longer 
possible to distinguish between a plugin component endpoint and a user-defined  
endpoint.

Therefore we've arrived at the following setup.

All the endpoints are exposed on their dedicated ingresses by default. All the 
endpoints (either "plugin" or user-defined) can OPT IN to be exposed on a 
subpath (by setting the `urlRewriteSupported` attribute on the endpoint to 
true).

The subpath exposure is achieved through an http gateway the same way as in 
che7 and there is an option to switch the gateway off, which in effect makes 
all endpoints exposed on subdomains, ignoring their potential request to be 
exposed on a subpath.

In another words, we've done away with the distinction between singlehost and 
multihost, because "multihost" is the inevitably default behavior while 
singlehost is what we want to achieve for devworkspace "plugins" under our 
control. Both subdomain and subpath endpoints are always going to be present 
in any non-trivial devworkspace.

==== CONSEQUENCES

* Let's stop referring to "singlehost" and "multihost" exposure - there's 
always going to be a mix of both. Let's instead talk about subdomain and 
subpath endpoints.
* We cannot get rid of the subdomain endpoints.
* We can make all our plugins endpoints subpath-capable (we already do in che7 
so for devworkspace, it should be a matter of flipping the 
`urlRewriteSupported` attribute on them to true)
* Auth can first support only subpath endpoints, leaving subdomain endpoints 
unprotected, because we can make sure all our auth-sensitive endpoints are on 
a subpath.
* We HAVE TO support auth on subdomain endpoints eventually, because devfile 
2.0 spec defines the `secure` attribute on the endpoint as requiring "https" 
and "some authentication process".
* DWO can be completely unaware of all this, because dwco is in charge of 
routing che devworkspaces (devworkspaces with the che routing class)

Do you see any other consequences (to theia plugins, dwo, etc..) that we've 
not identified?


Thanks,

Lukas