I had brought the idea up a few months back of mov...
# contribute
e
I had brought the idea up a few months back of moving Flyte routes under an ingress subpath -- and there have been several interested parties. We've gotten into the meat of the problem now and have it working in our environment, albeit with a minor change to flyteadmin and a minor change to the console (both of which have PRs and should be fully backwards compatible). I haven't put up the PR for the chart changes yet as there's a little more work there to make it land upstream (primarily it's necessary to use ingress regex support / url rewriting -- and I want to talk about implications there). Missed my chance on the call today to ask about this -- is there someone I should work with on helping to shepherd this through with @David Espejo (he/him)? Thanks!
f
Not all ingresses support path rewriting but since this will be backwards compatible and optional, this shouldn’t matter?
e
Yeah, I mentioned the ingress rewrite issue for exactly that reason... I'm not sure what people are using what ingresses with Flyte. So it might make more sense to have a new ingress definition that's only activated for subpath usage (if your ingress supports it) -- I would initially just target nginx, and people who wanted this could further extend support if they're not using something compatible
Longer term it might make sense to use Gateway resources -- where I think support for this kind of functionality is uniform across the various implementations... but that only went stable in k8s 1.29
f
We use a different ingress but we don’t configure it via the flyte helm chart. We disabled the ingress in the chart.
If we stick with
/console
, then it’s not a problem that our ingerss doesn’t support path rewriting, right?
e
Correct - that wouldn't be an issue for you
The regex only impacts the ingress in the chart
d
@Ethan Brown thanks for bringing this back 🙂 I think targeting NGINX is a good approach; it supports regex and path rewrites and several people use it here. If we make this completely optional and just a matter of annotations, I think is illustrative enough for folks who want to make it work with other controllers, or just for people who don't need that
e
Ok great! Being able to use regex in the ingress would also simplify the ingress definition a ton. I'll propose a few ideas in a PR to get the ball rolling since there are options here.
We are going to need to land two other small changes to accommodate this as well if someone could review: https://github.com/flyteorg/flyte/pull/5192 https://github.com/flyteorg/flyteconsole/pull/861