GEP-1713: ListenerSets - Standard Mechanism to Merge Gateway Listeners (rev 2)

[dprotaso]

This replaces #1863
What type of PR is this?

/kind gep

What this PR does / why we need it:

Outlines a mechanism to merge Gateway Listeners

Which issue(s) this PR fixes:

Fixes #1713

Does this PR introduce a user-facing change?:

NONE

[youngnick]

Quite a few comments here, thanks for keeping working on pushing this forward.

[robscott]

Thanks for all the work on this @dprotaso!

[youngnick]

This LGTM for Provisional (or maybe even Implementable, since we'll need to implement it and try it out) now.

[robscott]

Status update: We're at the end of the 2-day extension for this GEP to make it into this release, so unfortunately I think this is going to have to switch to targeting v1.3. Fortunately, this new shorter release cycle means that's actually not that far away.

Ultimately, I think you're right. For this to make sense, we'd need some structural changes to Gateway, particularly making Listeners optional. That's a huge change to a GA API (even if it would initially be limited to experimental channel, breaking changes to something labeled as "v1"can be confusing). Combined with the huge scope of the PR, and most of the feedback just coming from Nick and I, I think this particular GEP would benefit from some more soak time for additional reviewers + to smooth out any areas we're uncertain. Unfortunately, I think it's just too big to try to squeeze in today.

With that said, I would like to see this GEP make it in early in the next release cycle (similar to how named Route rules just barely missed the previous cycle but was merged at the beginning of this one).

I think it would be useful to do the following between now and then:

1. Continue to iterate on this GEP, discussing in meetings as necessary (this can include merging this as provisional with some unresolved sections and iterating in smaller PRs)
2. Build out a clearer vision for how this can be expanded to cover more use cases in the future (particularly the ones we discussed in the hierarchy doc) - that will help make a stronger case for why this is important
3. Present these ideas at the SIG-Network review session for v1.2 so we can get early feedback on this overall idea and adjust the proposal accordingly
4. Warn all controller authors that it's possible that Listeners may become optional in a future release of Gateway API and they should make sure they can handle that case

Thanks again for all the work you've been putting in to push this forward @dprotaso! I really do appreciate it.

[kate-osborn]

Just curious, why limit ParentRefs to 2?

[mikemorris]

My guess is to allow "moving" a set of listeners from one Gateway to another without downtime, but limiting the ability to attach the same set of listeners to many different Gateways - if we find sufficient demand for that pattern loosening this constraint in the future could be possible, but it feels like a pattern that likely should be avoided.

[robscott]

+1 to Mike's answer. @dprotaso do you mind capturing this rationale somewhere in the GEP?

[dprotaso]

Circling back on this I want to check the assumption - we sorta added multiple parents for 'future' proofing without a use case. See: #3213 (comment)

@mikemorris mentioned the migration as one use case but I don't particularly see that being any simpler than creating a copy of the ListenerSet.

I'd be willing to hear other use cases but so far I'm not convinced a list is the right thing here - especially if we're limiting it to 2 parents. It makes the status more complicated when we know the 80% of uses will be a single parent Gateway.

Again if we didn't have multiple parents a user could simply create two ListenerSets.

[dprotaso]

/retest

[robscott]

Thanks for all the work on this @dprotaso! Took a fresh pass and I think this largely makes sense.

[robscott]

+1 to Mike's answer. @dprotaso do you mind capturing this rationale somewhere in the GEP?

[robscott]

Thanks for capturing this!

+1 to past me on all points 🙃. I'd argue that we should probably make attempts at resolving both 1 and 2 here.

[youngnick]

For multiple hostnames, I can see the utility, but it risks making the rules about Listener -> Route hostname matching even more complicated.

[dprotaso]

Optional port would be nice - then let the implementation choose it. Though it's a rare use case for me.

[robscott]

Would like to get some resolution on #3497 before we release this API, as I'd prefer to switch this group to gateway.networking.x-k8s.io

[robscott]

There's been some renewed interest in pushing L4 + ClusterIP Gateways forward, and one thing that could help with that is if Listeners could point directly to backends. I'd personally like to explore that in this GEP as a follow up to the similar idea in the doc. (No need to take action here until we get some more comments/feedback on this idea).