Thank you Lukas for enhancing the ideas from my original email. It totally makes sense to me. If there are no objections, I'd like to start working on it after #17430 [1] will be merged.
[1] -
https://github.com/eclipse/che/pull/17430I'm in favor of the option 3 because it gives us the most room for the future.
In the current iteration we are going to basically just add another exposure
mode that is going to be equivalent to the current single host. For that
matter just another name for the "server_strategy", like "gateway" would work.
But in the future, we want to start making a distinction between the way how
we expose "infrastructural" parts of the workspace like plugins and editors
vs. user-defined parts of the workspace like dockerimage, k8s and openshift
components, or, eventually, all the apps started by the user within the
workspace.
So really, we're at a start of a journey to a much more fine-grained control
over the exposure of both the che server itself and the parts of workspaces.
Therefore, I would like to propose that we leave "server_strategy" alone as is
at the moment and add new properties that further define how single host
should really work.
I propose the following:
che.infra.kubernetes.single_host.workspace.exposure=(gateway|native)
This would set the "default" exposure for all the workspace components and
user-started apps. This is the only option that we would support in the first
iteration. "native" means "native to the cluster" and thus would mean
"ingress" on k8s and "route" on openshift.
Futher down the line, we can start adding more:
che.infra.kubernetes.single_host.workspace.plugin_exposure
che.infra.kubernetes.single_host.workspace.app_exposure
which could have "gateway", "native" or "pool" as values, where the former two
would mean the same thing as above and "pool" would be the envisioned limited
number of ingresses assigned to each user.
WDYT? Is this a good idea?
On Wednesday, July 22, 2020 3:46:56 PM CEST Michal Vala wrote:
> Hello Che devs,
>
> we're finally actually coding the new single-host strategy with
> Traefik gateway.
>
> We currently have `che.infra.kubernetes.server_strategy` with options
> `default-host`, `multi-host`, `single-host` and it is working only on
> Kubernetes. With new single-host approach we won't be using
> Ingresses/Routes for workspaces public endpoints, but we'll have only
> a single Ingress/Route for the whole Che and doing all routing with
> reverse-proxy (Traefik) that we will be configuring as we need.
>
> My question is, how do we want to configure it? I see following options:
>
> 1] silently replace single-host strategy. Simply configuration would
> be exactly the same, only with `single-host`, it will now use the new
> approach with no fallback to old Ingress based. And it will ofcourse
> work on OpenShift.
>
> 2] Introduce 4th strategy name. Something like `gateway-host`,
> `che-host`, `single-route-host` (I don't like either of them. We would
> make up something better if we choose this way)?
>
> 3] Have a second config option for single-host. So it will keep the
> `che.infra.kubernetes.server_strategy` as is, but when it is set to
> `single-host`, second config options came to play, something like
> `che.infra.kubernetes.singlehost_strategy` with options `ingress` for
> current implementation. For new impl either
> `traefik`/`traefik-gateway` for more variability in case we would need
> more gateway implementations. Or only `gateway` that would keep
> underlying gateway implementation hidden.
>
> 4] other ideas?
>
> I personally like the 3] as I think that `single-host` is a good name
> that describes it well, and with the second config option, we will be
> more future-proof. This might be important in cases we will need to
> add/switch gateways, or for example some interesting single-host
> strategies came up with IngressV2 or something new we currently don't
> know about.
>
> Thoughts?
>
> Thanks!
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
