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 @average-finland-92144? 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

We use a different ingress but we don’t configure it via the flyte helm chart. We disabled the ingress in the chart.

Correct - that wouldn't be an issue for you

@gorgeous-waitress-5026 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.