The conformance test suite should also search Accepted condition in Gateway.Status.Conditions.

[wstcliyu]

What would you like to be added: The conformance test suite tries looking for Accepted condition in Gateway.Status.Listeners.Conditions. It should also search Accepted condition in Gateway.Status.Conditions.
https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/utils/kubernetes/helpers.go#L716

Why this is needed: Some Gateway implementation only sets Accepted condition in Gateway.Status.Conditions.

[robscott]

Although the current conformance checks are per Listener, I do agree that these probably becomes unnecessarily verbose when a Gateway has lots of listeners:

gateway-api/conformance/utils/kubernetes/helpers.go

Lines 325 to 331 in 7320257

	// GatewayAndRoutesMustBeAccepted waits until:
	// 1. The specified Gateway has an IP address assigned to it.
	// 2. The route has a ParentRef referring to the Gateway.
	// 3. All the gateway's listeners have the following conditions set to true:
	// - ListenerConditionResolvedRefs
	// - ListenerConditionAccepted
	// - ListenerConditionProgrammed

When I'm thinking about potential alternatives, I think we'd end up with something like this:

1. Gateways must have top level conditions set for all of the conditions we currently require on Listeners
2. Listener conditions only need to be set when they differ from top-level Gateway conditions (ie all but one Listener is accepted, therefore Gateway is accepted + error conditions are set for the problematic Listener)

That kind of change would allow implementations to continue to set all of the conditions they already are, but no longer requires status to be quite as verbose. In any case, it's too late to make a change like this for v1.1, but definitely worth discussion in the v1.2 cycle.

/cc @youngnick

[youngnick]

We've defined these conditions as positive-polarity conditions, which means that the official contract for them is that they should always be present, because them not being present implies "not enough information to set this condition yet".

Doing something like this will require us writing out and then conformance testing all the rules to ensure that we get this right, and that everyone does at least the minimum.

What I don't want to have happen here is that implementations stop publishing any information altogether into Listener status, which will happen unless we carefully spec out the change here.

Making everything required is definitely more verbose but means that we are guaranteed accuracy in the Listener status.

@wstcliyu, as of right now, the conformance tests check that the Listener Conditions are set because they are required in the spec. We can make it optional, provided we define the rules and make sure those rules are tested properly by conformance. Until then, implementations need to populate all of the status to be conformant, sorry.

[robscott]

@youngnick how would you feel about a change to the spec that looked like this?

1. Gateways must have top level conditions set for all of the conditions we currently require on Listeners
2. Listener conditions only need to be set when they differ from top-level Gateway conditions (ie all but one Listener is accepted, therefore Gateway is accepted + error conditions are set for the problematic Listener)

[youngnick]

It's a pretty big change in intent for status for Gateways, so I think I'd like to think about it for a bit. I can't see immediate problems, but I'm worried about implicit assumptions and the changeover process.

The proposed change would essentially change all Listener Conditions to have negative-polariy behavior, but positive-polarity naming, which seems confusing.