GEP: Add support for Route inclusion and delegation

[Jeff-Apple]

What would you like to be added:
Add support for a 2-tier hierarchy of route configuration to allow partial delegation of route settings and, provide more flexibility in how route configurations are organized and managed.

The formal GEP document will be based on the following document but with some changes based on the feedback and discussions that have taken place since it was last modified: K8s Gateway API - Route inclusion and delegation

Why this is needed:

1. The current model for delegation in Gateway API, has only one point where gateway owners can delegate some of the route configuration; where Routes attach to Listeners. This is basically an all or nothing model with very little flexibility.

2. Some scenarios need multiple RouteRules to have a subset of configuration settings that are the same in all of them (e.g., a specific RouteFilter config). The RouteRules might be in the same Route or many Routes. The only way to currently do that is to administratively add those settings to each RouteRule. This can result in much larger Route configurations and, frequently, configuration drift over time.

Additional Information:
This issue is for tracking the progress of the PR containing the formal GEP document.

Link to PR: #1085

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[robscott]

/remove-lifecycle stale
/lifecycle frozen

[shaneutt]

Ultimately #1085 was auto-closed due to inactivity, so it would appear that for the moment we don't have anyone actively championing this effort and moving it forward. For now we'll consider it closed, but if anyone is interested in pushing for it please do feel free to ping here and we can re-open it any time.

[EItanya]

I am interested in this effort. However, I am interested in hearing other people's summary of the current state. It appears that the design doc and GEP were both very close to finished, but never agreed on. Can someone with more context potentially enumerate the existing issues with the design. It seems to be that the biggest issues come down to the re-use of the HTTPRoute as both a child and a parent, and the complexity inherent in that choice.

[youngnick]

Yes, the current state is that this is basically abandoned, because it's very difficult to define how the inclusion should work while still using HTTPRoute as the object.

I should also note that past experience says this will be a lot of work, so I think that interested folks should look at restarting with a fresh Github Discussion. But I think it's fair to say that this will require some pushing, as there are a number of other features currently higher on the priority list.

[EItanya]

That's fair, is there a list of current prioritized items?

[shaneutt]

I don't recall us leaving this with any sort of playbook about what to do next 🤔

My perspective: while I think there's plenty of prior art to consult here, I think the next step for you as someone interested would be to propose a "What" and "Why" in something like a GitHub discussion (and also put it on the meeting agendas to discuss periodically), basically as a new effort that references the old one: let's try to determine with strong clarity what we want to do and why we want to do it, with no "how" we do it yet. I personally would particularly want to see more user stories that help to show the value to Gateway API end-users. Through that discussion process we should gather at least one (if not multiple) other implementers who need this and are in alignment on the what and why. If we can establish that, this might be good grounds for a re-open, or maybe more appropriately a new GEP inspired by the original work.

Does that make sense, and is that helpful to you?