Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] How to configure new Single-host ?

I like the option 3) for the very same reasons as you. With it, we can support 
ingressv2 in the future or any other way of doing it. That way we don't tie 
our users to a solution that might not fit their security strategy for example 
(I assume ingressv2 will have many more knobs to turn than we will ever be 
able to support ourselves).

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!






Back to the top