Should route controller take into account ListenerStatus.SupportedKinds?

[pmalek]

Given

gateway-api/apis/v1beta1/gateway_types.go

Lines 656 to 666 in a8f72f5

	// SupportedKinds is the list indicating the Kinds supported by this
	// listener. This MUST represent the kinds an implementation supports for
	// that Listener configuration.
	//
	// If kinds are specified in Spec that are not supported, they MUST NOT
	// appear in this list and an implementation MUST set the "ResolvedRefs"
	// condition to "False" with the "InvalidRouteKinds" reason. If both valid
	// and invalid Route kinds are specified, the implementation MUST
	// reference the valid Route kinds that have been specified.
	//
	// +kubebuilder:validation:MaxItems=8

should an implementation of route controller take into account ListenerStatus.SupportedKinds?

It seems to me that this is purely informational.

If, in some case this should be taken into account then what reason should be used when the route kind is not in the supported kinds?

[howardjohn]

There is only 1 controller - which controls Gateway and Route. I don't think there can be a split brain controller (?). Given this, the thing programming routes and writing the status are the same thing.

The controller should take this into account, although literally reading from Status may not be the best way to implement it.

[youngnick]

Good discussion, thanks everyone.

I think that what I want to say is something like the official position on Conditions: They're made primarily for humans, rather than for machine consumption. That doesn't mean you can't or shouldn't use them, just that you should be careful if you do.

Nothing I've worked on assumes that they'll be static, but I just haven't ever keyed anything off changes, because of the raciness concerns I listed.

[pmalek]

how to react to changes in SupportedKinds throughout the lifecycle of a Gateway resource" the problem we're trying to solve and we're on the same page

Partially yes. I'd say I'm also not sure how to react to them in general (see below).

I'm not 100% convinced what to do in situations like e.g.: user defined Listener.AllowedRoutes, the implementation posts its SupportedKinds in ListenerStatus and it cannot support at least one of the route type from the specified Listener.AllowedRoutes. Should those be subsequently allowed or not? Am I the only one seeing this discrepancy or am I the only one missing something 😅 ?

[youngnick]

Ah, I thought that only the union of those two sets of things would be valid - if a user allows routes that an implementation doesn't support, then it's expected that the implementation would not accept those routes. (It can't support them, anyway!)

In that case, the SupportedKinds is intended as a hint for the user to see what Routes are supported, but the implementation also should record that the unsupported Route's attachment to its parentRef failed because the Kind is not supported by that Gateway implementation. Does that make sense?

So, the SupportedKinds is more a hint for the user about what the implementation is capable of doing, not a request for anything. (In general, status is intended to record the response from "the system" (being Kubernetes and all the installed controllers) about what's been requested in the spec.

It does seem like this could use clarification though.

[pmalek]

Got it. So basically instead of checking the SupportedKinds we should "defer" to the implementation to reject that.

Maybe the fact I was even questioning this approach is that I'm biased by Kong's implementation which has several layers of verification whether e.g. a route could be attached and instead of invalidating it at the gateway level and relying on error received from it (which would be hard to then untangle and write status updates for) we opted in (for now) to look at the status and have that information readily available at that point (where we now for each entities we failed to attach).

Does that make sense? 🤔

[youngnick]

I think so, I guess I've always assumed that an implementation will know what Kinds it supports in itself, so you shouldn't need to check the SupportedKinds. But if the same thing is setting the status and reading it, I guess it's fine (if a little odd).