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

[Lukas Krejci <lkrejci@xxxxxxxxxx>]

On Wednesday, April 14, 2021 6:06:12 PM CEST Mario Loriedo wrote:
> 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?
> 

+1

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

In a sense, yes, this is easier. On the other hand we can no longer make 
different default choices based on whether an endpoint comes from a plugin or 
not (e.g. devfile v1 is default subpath for plugins and default subdomain for 
devfile endpoints).

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

Yes, exactly. While we had to change the default for the "plugins", we are 
still in control of our own plugin definitions and can make the adjustments so 
that subpath deployment is supported if needed.

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

Yes, this works both on k8s and openshift.

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