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

[davidjumani]

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]

cc @rikatz @dprotaso

[robscott]

cc @rostislavbobo @mkosieradzki

[rikatz]

@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]

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]

should this accepted here be false?

[davidjumani]

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

[rikatz]

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

[rikatz]

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

[davidjumani]

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

[rikatz]

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

[rikatz]

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

[davidjumani]

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

[rikatz]

@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]

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

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