GEP-2643: TLSRoute#4064
Conversation
k8s-ci-robot
added
release-note
k8s-ci-robot
added
do-not-merge/hold
geps/gep-2643/index.md
Outdated
| * When a Gateway contains a listener with `protocol=TLS` and `tls.mode=Passthrough`, | ||
| the `Gateway` MUST NOT allow another listener on the same port with a different | ||
| `tls.mode` and the `Gateway` SHOULD be marked as `Accepted=False`. | ||
| * Any violating Listener should have a Condition `Conflicted=True`. |
There was a problem hiding this comment.
From a discussion that we had: is this for any listener, for the one added later? If there is a conflict listener on the TLSRoute case, do we want to mark all of Listeners as conflicted? Should we stop serving in this case, and mark Accepted=false?
Per @Miciah comment:
The GatewaySpec godoc is explicit: 'If a set of Listeners contains Listeners that are not distinct, then those Listeners are Conflicted, and the implementation MUST set the "Conflicted" condition in the Listener Status to "True"', and, "The implementation MUST NOT pick one conflicting Listener as the winner."
The godoc for ListenerConditionOverlappingTLSConfig re-iterates: "This condition MUST be set on all Listeners with overlapping TLS config."
- what if we have a conflict? Do we really want all of the listeners to be gone?
- what if we are using ListenerSet?
There was a problem hiding this comment.
I have changed here for now as:
* When a Gateway does not support [Multiplexing](#multiplexing-support) and contains
a listener with `protocol=TLS`, the Gateway MUST NOT allow any other kind of
listener on the same port, and any violating Listener should have a Condition `OverlappingTLSConfig=True`
with the reason `OverlappingProtocols`.
This is a new condition that we should be adding
There was a problem hiding this comment.
Hmm, the suggestion to mark all listeners as conflicted feels at odds with the typical conflict resolution guidance in https://gateway-api.sigs.k8s.io/guides/api-design/#conflicts, but I think maybe we aren't able to follow that because listener config is all batched together as an atomic update to the Gateway (and trying to be "stateful" rather than reflecting the current YAML is an anti-pattern)?
(I think the most granular breakdown achievable might be one entire ListenerSet attached to a Gateway becomes conflicted, but other ListenerSets attached to the same Gateway remain functional.)
There was a problem hiding this comment.
@mikemorris I think this is currently solved? As we are keeping ListenerSet out of this GEP, I will consider the conflict management fully part of ListenerSet
|
To be added: #3541 |
rikatz
force-pushed
the
tlsroute-gep
branch
from
837ebfb to
033815b
Compare
|
/assign |
|
A side note to myself, I want to open 2 more GEPs thjat will complement this:
|
k8s-ci-robot
removed
the
needs-rebase
k8s-ci-robot
added
the
lgtm
|
LGTM once with some minor changes. Nice work @rikatz and @rostislavbobo! |
Co-authored-by: Nick Young <[email protected]>
k8s-ci-robot
removed
the
lgtm
|
Thanks Nick, I will do a final review/pass on the feature names case here, and will let you know! |
|
@youngnick thanks! my last commit fixed the feature names on the conformance tests and removed a long term goal that should have been removed (ESNI is dead, the new feature is ECH) |
|
This LGTM, thanks @rikatz! I'll approve and unhold so that the next LGTM will merge. /approve |
k8s-ci-robot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rikatz, rostislavbobo, youngnick The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
Thanks @youngnick for your suggestions! /lgtm |
k8s-ci-robot
added
the
lgtm
* GEP-2643: TLSRoute * Add multiplexing to TLSRoute * Update TLSRoute GEP with more information * Add support for TLSRoute termination * Fix some comment reviews * Move multiplexing to its own GEP * Fix gatewayapi reviews * Fix some more reviews * Fixes on some wording * Add reference to other GEPs * Add conformance for non supported termination * Add conformance, fix mixed mode, fix metadata * Be explicit on conformance intent for failed listener * Add conformance issues and codes to conformance table * Address comments on GEP * address comment reviews, add tlsmode validation * Apply suggestions from code review Co-authored-by: Nick Young <[email protected]> * Fix feature names on TLSRoute gep --------- Co-authored-by: Nick Young <[email protected]>
9 participants
What type of PR is this?
/kind gep
What this PR does / why we need it:
Adds the TLSRoute GEP, which is a document aggregating all of the existing TLSRoute implementations and also adding some disambiguation discussions
Which issue(s) this PR fixes:
Fixes #2643
Does this PR introduce a user-facing change?:
This GEP is targeting v1.5