Re: [che-dev] How workspace routing works in devworkspace compared to ch

[Mario Loriedo <mario.loriedo@xxxxxxxxx>]

Thank you Lukas for your detailed explanation. That helps.

One thing I've noticed is that you compare DevWorkspace vs Che 7. To avoid confusion there is no plan to release a v8. The version of Che that will run dwo-based workspaces is Che 7. We may use devfile v1 vs devfile v2 to distinguish the 2 engines in the future?

 

it is no longer possible to distinguish between a plugin component endpoint and a user-defined endpoint.

That's surprising. In v2 devfiles we do not have plugins anymore, everything in a devfile is user defined. Hence I would have expected that to be easier.

That said it doesn't look like an issue since we do control che-theia plugins definitions (the devfiles are automatically generated) and we can set urlRewriteSupported to true if needed.

The implementation that you have described works for both k8s and openshift right?

On Wed, Apr 14, 2021 at 12:46 PM Lukas Krejci <lkrejci@xxxxxxxxxx> wrote:

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




_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev