Revise GEP-1713: Update gateway status and conformance test details for ListenerSets #4205

davidjumani · 2025-10-28T15:41:16Z

What type of PR is this?
Add one of the following kinds:
/kind documentation
/kind gep

Optionally add one or more of the following kinds if applicable:
/area conformance-test

What this PR does / why we need it:
This PR does the following :

Adds the list of conformance tests to be added to ListenerSets (GEP-1713)
Updates the status of the Gateway to include AttachedListeners that is the count of successful ListenerSet attachments to the gateway. Ref: slack theraad

The aim is to get consensus for the set of conformance tests required to validate this feature against implementations, and move towards promoting this to Standard

Does this PR introduce a user-facing change?:

Adds the `AttachedListeners` conditions to the Gateway status for the GEP and details for ListenerSets conformance tests

davidjumani · 2025-10-28T16:28:07Z

cc @rikatz @dprotaso

robscott · 2025-10-28T16:32:38Z

cc @rostislavbobo @mkosieradzki

rikatz · 2025-10-28T16:39:29Z

@davidjumani thanks, this is a great write of conformance. Do you think it makes sense to also add the expected conditions on each conformance item, and also the ancestorStatus expected, to make it clear to implementations what we will look for?

davidjumani · 2025-10-28T20:54:39Z

Do you think it makes sense to also add the expected conditions on each conformance item

I intentionally left them out right now in case there's any discussion to be had when the conformance tests are in review. Happy to add them now if that would clarify things and make reviewing the tests easier.

Added the expected status as well as added the AttachedListeners status that is the count of successful ListenerSet attachments to the gateway. Ref: slack theraad

rikatz · 2025-10-30T11:54:09Z

geps/gep-1713/index.md

+    - The ListenerSet has the following status :
+      | Type    | Status | Reason |
+      | -------- | ------- | ------- |
+      | Accepted  | True    | ListenersNotValid |


should this accepted here be false?

Based on the GEP

// This can be the reason when "Accepted" is "True" or "False", depending on whether // the listener being invalid causes the entire Gateway to not be accepted.

I believe this should be true since the ListenerSet is configured but does not adversely affect the parent Gateway.
Additionally, there can be a scenario where only a subset of the listeners is invalid and this would more accurately reflect it

but then the reason should be empty or something else, right? It was accepted but not programmed, I guess

+1. If the status is Accepted, there should not be a reason for that.

I wouldn't also mix Accepted: True and Programmed: False in this case. The Programmed condition indicates whether the controller was physically able to apply the requested resources (e.g. allocate an IP or open a port). Listener conflicts are configuration errors, not the controller ability to program them.

I don't think so. A subset of listeners can be accepted, so the status should reflect it accordingly.
If not all listeners are accepted, then the listenerSet Accepted condition should be false.

Additionally, the Programmed condition should also reflect the same, since a subset of listeners was applied

rikatz · 2025-10-30T11:55:03Z

geps/gep-1713/index.md

+    - The parent gateway has the following status :
+      | Type    | Status | Reason |
+      | -------- | ------- | ------- |
+      | AttachedListenerSets  | False    | ListenerSetsNotAllowed |


do we really need this condition on the parent gateway? I am wondering if in Gateway case we can just not have any count of attached listener, as mostly the user will have its own condition

I think the condition should be set since :

The user has explicitly disallowed ListenerSets

ListenerSets have been attached (at least tried) to the Gateway

The user should know about this in the status

I am not aware of the whole conditions reasoning here tbh, will defer to @youngnick for some better view on it

rikatz · 2025-10-30T11:57:26Z

geps/gep-1713/index.md

+    - The newer ListenerSet has the following status :
+      | Type    | Status | Reason |
+      | -------- | ------- | ------- |
+      | Accepted  | True    | ListenersNotValid |


again, should we have an accepted here? And a reason? Not sure if this doesn't get more confusing

I think this is a better indication that the listenerSet is correct (the parentref is valid, etc.) but one or more of the listeners is invalid which is indicated by the ListnerStatus above

but one or more of the listeners is invalid which is indicated by the ListnerStatus above

If all listeners in the ListenerSet have conflicts, shouldn't we report the ListenerSet as not accepted? This is consistent with other resources (e.g. if an HTTPRoute has no hostname intersection with a Gateway listener, it's reported a not accepted).

Yes, I agree and will update it accordingly. I'll make this clearer with the total number of conflicting listeners

rikatz · 2025-10-30T11:58:52Z

@davidjumani overall lgtm! I would like us to keep separated a PR that changes the GEP from a PR that changes the API, this way if we need to track any (or revert) we have proper changes

Thanks again for the effort here!

k8s-ci-robot · 2025-10-30T15:12:07Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: davidjumani
Once this PR has been reviewed and has the lgtm label, please assign aojea for approval. For more information see the 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

davidjumani · 2025-10-30T15:13:29Z

Thanks for the review @rikatz I've answered the open questions and reverted the API changes.
Raised api: Update gateway status to include AttachedListeners with the changes

rostislavbobo

Thanks @davidjumani for a great conformance writeup! Left a couple of comment, let's discuss them today.

rostislavbobo · 2025-11-10T12:24:20Z

geps/gep-1713/index.md

+They will validate the following scenarios :
+
+1. AllowedListeners is not specified on the parent Gateway
+    - `Gateway.spec.allowedListeners` is not specified (defaults to None)


I am missing here and in the scenarios below whether the Gateway itself has listeners defined. This could change the statuses below and the outcome, for example, if Gateway listeners and ListenerSet listeners share the same port.

Can we be explicit and state that the Gateways have no listeners defined?

Currently, the Gateway validation requires at least one listener to be defined. I based the tests on this restriction

gateway-api/apis/v1/gateway_types.go

Line 236 in f24f3a6

// +kubebuilder:validation:MinItems=1

rostislavbobo · 2025-11-11T12:38:41Z

geps/gep-1713/index.md


 - https://docs.google.com/document/d/1qj7Xog2t2fWRuzOeTsWkabUaVeOF7_2t_7appe8EXwA/edit
+
+## Conformance Details


Should we clarify that the status is reported per parentRef? A ListenerSet can have different acceptance statuses depending on the Gateway configs it is attached to.

A listenerSet can have only one parent as per

gateway-api/apisx/v1alpha1/xlistenerset_types.go

Line 79 in f24f3a6

ParentRef ParentGatewayReference `json:"parentRef"`

Hmmm, I can't recall if there was any substantial discussion around this previously, but it could be possible to add a pluralized version of this field in some future revision if use cases demanded it. I'd kinda rather get the status nesting per-parentRef now (even if it feels redundant/unnecessary, it would mirror similar patterns on many other GWAPI resources) rather than deal with trying to add nesting to an assumed-singular hierarchy later...

rostislavbobo · 2025-11-11T13:04:24Z

geps/gep-1713/index.md

+    - The ListenerSet has the following status :
+      | Type    | Status | Reason |
+      | -------- | ------- | ------- |
+      | Accepted  | True    | ListenersNotValid |


+1. If the status is Accepted, there should not be a reason for that.

I wouldn't also mix Accepted: True and Programmed: False in this case. The Programmed condition indicates whether the controller was physically able to apply the requested resources (e.g. allocate an IP or open a port). Listener conflicts are configuration errors, not the controller ability to program them.

rostislavbobo · 2025-11-11T13:10:59Z

geps/gep-1713/index.md

+    - The newer ListenerSet has the following status :
+      | Type    | Status | Reason |
+      | -------- | ------- | ------- |
+      | Accepted  | True    | ListenersNotValid |


but one or more of the listeners is invalid which is indicated by the ListnerStatus above

If all listeners in the ListenerSet have conflicts, shouldn't we report the ListenerSet as not accepted? This is consistent with other resources (e.g. if an HTTPRoute has no hostname intersection with a Gateway listener, it's reported a not accepted).

rostislavbobo · 2025-11-11T13:25:18Z

geps/gep-1713/index.md

+      | AttachedListenerSets  | // depends on whether there are any other valid listeners in the attached ListenerSets // | ListenerSetsAttached |
+      | AttachedListeners  | // total number of child listenerSets // |  |


Let's be clear on numbers and Gateway setup (also see comment). We spend a decent amount of time pondering various options that result in different calculations and statuses, so it'd be grate if we could disambiguate.

I would prefer that we iron this out in the conformance tests. These serve more as guidelines, as we can always add more tests and update this later. I would like to get something in that we can work towards rather than making a comprehensive test plan that only stays in review

Add conformance details to ListenerSets (GEP-1713)

c1abb2b

k8s-ci-robot requested a review from howardjohn October 28, 2025 15:41

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 28, 2025

k8s-ci-robot requested a review from mikemorris October 28, 2025 15:41

davidjumani mentioned this pull request Oct 28, 2025

tests: Add conformace tests for listenersets #3890

Open

add conditions

b4bc6e8

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 29, 2025

update api

d7a8143

davidjumani changed the title ~~Add conformance details to ListenerSets (GEP-1713)~~ Revise GEP-1713: Add status update and conformance test details for ListenerSets Oct 29, 2025

k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels Oct 29, 2025

davidjumani changed the title ~~Revise GEP-1713: Add status update and conformance test details for ListenerSets~~ Revise GEP-1713: Update gateway status and conformance test details for ListenerSets Oct 29, 2025

davidjumani added 2 commits October 29, 2025 11:03

codegen

83344de

make attachedListeners optional

7e11433

rikatz reviewed Oct 30, 2025

View reviewed changes

remove api changes

fe7a3f1

rostislavbobo reviewed Nov 11, 2025

View reviewed changes

davidjumani mentioned this pull request Nov 19, 2025

STD: ListenerSets (GEP-1713) #4249

Open

1 task


		- https://docs.google.com/document/d/1qj7Xog2t2fWRuzOeTsWkabUaVeOF7_2t_7appe8EXwA/edit

		## Conformance Details

		\| AttachedListenerSets \| // depends on whether there are any other valid listeners in the attached ListenerSets // \| ListenerSetsAttached \|
		\| AttachedListeners \| // total number of child listenerSets // \| \|

Revise GEP-1713: Update gateway status and conformance test details for ListenerSets #4205

Are you sure you want to change the base?

Revise GEP-1713: Update gateway status and conformance test details for ListenerSets #4205

Conversation

davidjumani commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidjumani commented Oct 28, 2025

Uh oh!

robscott commented Oct 28, 2025

Uh oh!

rikatz commented Oct 28, 2025

Uh oh!

davidjumani commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rostislavbobo Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rikatz commented Oct 30, 2025

Uh oh!

k8s-ci-robot commented Oct 30, 2025

Uh oh!

davidjumani commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rostislavbobo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidjumani Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikemorris Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rostislavbobo Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidjumani Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

davidjumani commented Oct 28, 2025 •

edited

Loading

davidjumani commented Oct 28, 2025 •

edited

Loading

rostislavbobo Nov 11, 2025 •

edited

Loading

davidjumani commented Oct 30, 2025 •

edited

Loading

davidjumani Nov 18, 2025 •

edited

Loading

mikemorris Nov 18, 2025 •

edited

Loading

rostislavbobo Nov 11, 2025 •

edited

Loading

davidjumani Nov 18, 2025 •

edited

Loading