I had brought the idea up a few months back of mov...
# contribute
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!
Not all ingresses support path rewriting but since this will be backwards compatible and optional, this shouldn’t matter?
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
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
, then it’s not a problem that our ingerss doesn’t support path rewriting, right?
Correct - that wouldn't be an issue for you
The regex only impacts the ingress in the chart
@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
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