Enhancing GatewayClass Status API - policies/extensions support

[LiorLieberman]

We want to be able to represent policies/extensions the GatewayClass support.

Starting this discussion to gather thoughts and ides on this topic.

[LiorLieberman]

A new object under the GatewayClassStatus API looks like the ideal place for it.

The object could be a list of elements (every element consist of an API group and Kind)

This list will include the policies and extensions the GatewayClass (aka the implementation) support.

The hard question (and perhaps should not be completely resolved now) is what "support" means?

We have no policies in the main API yet, so, at first, I assume every implementation would only support custom extensions it developed.

But as we go we are likely to add common policies to the API. #1731 as an example.
Would support means, I support all the fields of a policy ?

Also, should we restrict this field to only extensions that take GW-api resources as a targetref?
I may be wrong but it seems that linkerd implements something that looks like a policy but its targetref is not a gw-api resource
@kflynn maybe you can advise on that

[youngnick]

I think that we should leave the definition a little vague here and say something like "resources relevant for the Gateway API implementation", with some guidelines like:

• resources used as ExtensionFilters or other extension points
• resources used as GatewayClass paramsRef targets
• resources used as Policy

Conceivably, we could also have an optional string field that listed a purpose, with some constants like Policy, ExtensionFilter and so on provided.

We need to make sure that we're not ruling out Policy objects that target core objects like Service or Secret as well with this definition. We can tighten up later a bit if needed, but I suspect that convention will be the best way here.

I'm definitely +1 on this idea, I was going to recommend something specific for Policy Attachment anyway.

[shaneutt]

How do you see this co-existing with the existing declarative parametersRef?

[youngnick]

Any CRDs used by an implementation would need to be listed here, including any CRDs used for parametersRef.

The intent, in my mind, is to give users a place to go to find out what they should look for in the cluster in the event they need to find extra things like Policy or ExtensionFilters.