GEP: GatewayClass status supported features

[LiorLieberman]

What would you like to be added:
Improve UX by enabling them to easily see what features their installed GatewayClass support.

Why this is needed:
With the evolution of the Conformance tests suite and features, we want to;

1. Enable users easily see what features the implementation support
2. Improving UX and potentially provide clear errors when a user is trying to use a feature the installed GWC doesn't support

cc: @shaneutt

[LiorLieberman]

/kind gep

[LiorLieberman]

/remove-help

[robscott]

Leaving open until this reaches GA.

/reopen

[k8s-ci-robot]

@robscott: Reopened this issue.

In response to this:

Leaving open until this reaches GA.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[LiorLieberman]

PRs in flight:
envoyproxy/gateway#2491
istio/istio#48770

[shaneutt]

We discussed this on a Gateway API sync: it may be helpful if we package in the conformance part in the initial delivery of this, as that might be a helpful way to encourage implementations.

[mikemorris]

@robscott Have you thought about how GKE might handle this (given the whole lack of in-cluster GatewayClass resources approach we share on AKS) if we try to go in the direction of using this advertisement of supported functionality to configure the conformance suite?

EDIT: I was wrong, we do actually deploy a GatewayClass into the cluster (just don't supported a user-defined GatewayClass), so we shouldn't be blocked here.

/cc @snehachhabria

[snehachhabria]

@robscott Have you thought about how GKE might handle this (given the whole lack of in-cluster GatewayClass resources approach we share on AKS) if we try to go in the direction of using this advertisement of supported functionality to configure the conformance suite?

EDIT: I was wrong, we do actually deploy a GatewayClass into the cluster (just don't supported a user-defined GatewayClass), so we shouldn't be blocked here.

/cc @snehachhabria

that's right, we do have predefined in-cluster GatewayClasses, so no issues form our end.

[LiorLieberman]

For some reason I though I left a comment here but apparently I did not. Anyway, I can confirm that within GKE GatewayClasses are also visible from within the cluster

[arkodg]

thanks @levikobi for adding support for this in Envoy Gateway ! sharing some thoughts after seeing it in action

• biggest value prop here is for users who can figure out which features the implementation supports, however just the name is not enough here, and a URL to the feature page would be great here, to make this more actionable and avoid searching how to use the feature
• the current flat structure if going to get hard to consume for the user soon once we add more support for more things and tests
• implementations may choose to use this field to highlight any extra features they support, to increase feature usage