GEP-1713: Standard Mechanism to Gateway Merge 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.

[mlavacca]

/cc @mlavacca

[robscott]

Thanks for all the work on this @dprotaso! I think this is heading in a good direction, but just lots of details + edge cases to work out still.

[robscott]

This feels like a rather scary change to me. Do we need this to start? Ultimately relaxing validation like this means that every Gateway API implementation needs to deal with empty Gateways, even if they're only theoretically useful when combined with ListenerSets.

[dprotaso]

Other folks feel pretty strongly about this

see: #3213 (comment)

[robscott]

This GEP is missing guidelines for when Listeners are "compatible" or can safely be merged together, is that meant to be part of this GEP or is it a non-goal?

[youngnick]

tbh I think that one of the best things about this proposal is that we can let go of the compatible language, since we're being explicit on the fact that Listeners must be distinct across ListenerSets - meaning that the combination of the primary key fields (port, protocol, tls details, and, dependent on protocol, hostname) must be unique.

Practically, to be compatible, Listeners used to have to be distinct anyway, so I think that having the additional complexity of allowing merging has not bought us anything except confusion - quite a few people have asked me about what the difference between "distinct" and "compatible" is.

[dprotaso]

It's hard for me to know what action to take here - it seems like this discussion is beyond this GEP and applies to regular Gateway listeners.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dprotaso
Once this PR has been reviewed and has the lgtm label, please assign mlavacca for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• geps/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[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.

[k8s-ci-robot]

@dprotaso: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-gateway-api-crds-validation-4	8b338bc	link	true	/test pull-gateway-api-crds-validation-4

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.