Unsupported feature warning mechanism

[shaneutt]

What would you like to be added:

A mechanism by which implementations can clearly indicate when they don't support a particular feature and raise that to end-users who try to use the feature.

Why this is needed:

Presently if an end-user tries to use a feature on any given implementation (without having first thoroughly read the docs) it may be very unclear why that feature doesn't work if the implementation doesn't support it. As an improvement to UX it would be nice if implementations can implicate the features they do or do not support so that this can bubble up to the end-users.

Additional Notes:

I'm aware of two proposed ideas for the implementation of this historically:

• using statuses to do this on individual objects
• using the status on GatewayClass to indicate feature support, therefore enabling the validating webhook to make enforcements before the offending configurations can even be stored

We should consider those and any other options and make a small GEP for this to make sure we have consensus amongst stakeholders.

This relates slightly to #1709 and we should consider where there may be cross-pollination.

[LiorLieberman]

/assign @LiorLieberman

[shaneutt]

Hey @LiorLieberman 👋 just checking in. Let us know if you need any help moving this forward, have any questions, e.t.c.

[LiorLieberman]

As discussed, I opened a discussion item about it #2108.

Will try to follow up with a GEP OR expanding the conformance profiles GEP next week.

The first iteration would be enhancing the API, we will follow up with the webhook work once we have a few implementations already reporting features in the GWC status.

[LiorLieberman]

GatewayClassStatus enhancement to include the features is covered by #2163 and is implemented in #2461.

What do you want to do with this issue? I think we should wait until we see more implementations of the SupportedFeatures in status and then revisit the warning mechanism. It may also fit to be a gwctl command

[shaneutt]

I don't want to see it become only a gwctl command as I think functionality should be exposed through the API as much as possible, but obviously it would be fine if gwctl has some special handling of it for convenience.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[gauravkghildiyal]

/area gwctl
(Adding a tag for better tracking, but I agree with the sentiment from Shane in #1804 (comment) that this isn't necessarily restricted to gwctl)

[LiorLieberman]

/remove-lifecycle rotten