Repository: kubernetes-sigs/gateway-api

Issue #1804: Unsupported feature warning mechanism
Created: 2023-03-10T01:56:20Z
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.

Duplicate issue #482: Define standard conformance format for a GatewayClass to communicate what it supports to operators
Created: 2020-11-25T14:47:00Z
What would you like to be added:
GatewayClasses encapsulate the capabilities that an implementation of Service APIs supports. However, for the platform operators or application operators who might deploy Gateways in a cluster may not know exactly what within the API a given GatewayClass supports. This issue proposes a standard way for all GatewayClasses to communicate to a user what it supports.
Let's say I have an acme-lb GatewayClass. The GatewayClass should be able to tell me the following:
kind: Gateway
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: supported
spec:
  gatewayClassName: supported
  listeners:  
  - protocol: 
      http: supported
      tcp: unsupported
      udp: unsupported
    port: supported
    routes:
      kind: 
        HTTPRoute: supported
        TCPRoute: unsupported
        UDPRoute: unsupported
      selector:
        matchLabels: supported
...
---
HTTPRoute:
  spec:
    hostnames: supported
    rules:
    - matches:
      - path:
          type: 
            prefix: supported
            exact: supported
            regularexpression: unsupported
            implementationspecific: unsupported
        headers:
          type:
            exact: supported
            implementationspecific: 
              contains: supported # Will match traffic with any single header that contains this string
              doesnotcontain: supported # Will match traffic if no headers contain this string 
...

This is a terrible example of the format but you get the idea :) Perhaps OpenAPI has some kind of capability for this.
The goals this aims to achieve:

Provide a standardized way for all GatewayClasses to communicate which aspects of the API they support.
Core fields must be supported to achieve conformance, but since extended fields can be optional it will be very useful to understand which extended fields are implemented by a given GatewayClass.
Custom fields (like annotations, ImplementationSpecific fields, or CRDs that can be referenced) should also be able to be communicated in some way so operators can understand how a GatewayClass has been extended with additional functionality.
Provide a way for the provider to give additional context to describe implementation-specific aspects of a core, extended, or custom field. The example above with contains illustrates this.

How a GatewayClass provider communicates to the operator what its capabilities are can be done in many different ways:

Perhaps conformance tests spits this out as a standardized output and providers can simply put this in their docs
Perhaps comments or fields within a GatewayClass implementation can fill out these fields. This would give the opportunity for implementors to add special comments and context regarding support for specific fields. This might be the case where a field is supported but how it functions requires more context or explanation.

cc @robscott

Closing comment (2023-03-10T15:43:14Z): Indeed, for anyone visiting this issue please consider it a duplicate of #1804 and follow up over there 👍