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.

[youngnick]

Reading back over this, I think the main things outstanding are:

• Will we start this off with the separate experimental API group (as per New Experimental APIs should start in x-k8s.io API Group #3497)?
• Will we make port optional in the ListenerSet version of Listener?
• Will we keep the parentRef as a list or move it back to a singular one?

[robscott]

• Will we start this off with the separate experimental API group (as per New Experimental APIs should start in x-k8s.io API Group #3497)?

I'm strongly in favor of this, and the idea seems to be gaining some traction on the corresponding issue.

• Will we make port optional in the ListenerSet version of Listener?

I would like to ensure that this has a well documented path forward to supporting all ports on a single Listener. That could either be a port range or an empty port. We don't have to start with either of those, I'd just like to have a documented plan for how we could get there.

• Will we keep the parentRef as a list or move it back to a singular one?

I'm on the fence on this one, left a comment above.

[mikemorris]

I would like to ensure that this has a well documented path forward to supporting all ports on a single Listener.

Could make sense to align with NetPol conventions on this (omitting an optional port field implies all), refs kubernetes-sigs/network-policy-api#247 (comment)

[dprotaso]

I was thinking an empty port could be allow the implementation to pick a random port. Though I realize now we could also accomplish that by relaxing our constraints on PortNumber and allowing 0 (unix semantics). If we do that then I don't particularly need an optional port - so I'm curious about other people's use cases.

I think use of port in netpol is fundamentally different than that of a listener - eg. firewall rules semantics (no port == all) vs listener semantics (0 port = wildcard)

[mlavacca]

I think that including L4 considerations at the very first stage of the design, before having the actual API in place is too much of a stretch. Getting rid of L4 routes in favor of including L4 routing information (i.e., backends) is a controversial one (for which I am on the fence honestly) and I don't think that should block this GEP which has been in the work for a long time and needs to be moved forward.

Putting here L4 will likely require a lot of discussion, partially off-topic with the broader goal of this GEP.

[mlavacca]

Once others' comments are addressed, I'm ok with moving this one forward. Thanks, @dprotaso!

/approve

[dprotaso]

So an observation I have regarding multiple parentRefs would make certain future changes/features incompatible.

For example we're talking about making port optional here and I was suggesting we could allow implementations to choose a port here but then this wouldn't be possible with multiple parentRefs since different implementations would most likely choose a different port.

Also reasoning about policy might be simpler because we can say this ListenerSet has this inherited policy from the Gateway. With multiple parentRefs that's not really possible and it limits the ListenerSet to simply add these extra listeners to these gateways.

[dprotaso]

/hold

given that parentRefs was added as a way to 'future proof' (#3213 (comment), (#3213 (comment))) rather than being born from a real use case - I'm included to switch this to a single parentRef

[robscott]

Thanks @dprotaso! This looks good to move forward to the next phase of the v1.3 cycle.

Of course we'll still need to do some refinement in the next phase, and should probably have some more discussion around the most recent changes (single ParentRef, optional port), so let's start that discussion very early to ensure we can get a final API merged in.

/lgtm
/approve
/hold cancel

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dprotaso, mlavacca, robscott

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

The pull request process is described here

Needs approval from an approver in each of these files:

• geps/OWNERS [mlavacca,robscott]

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

[dprotaso]

let me make the single parentRef changes to the GEP before merge
/hold

[dprotaso]

/hold cancel

[robscott]

/lgtm