You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enrich the documentation of GEP-2162 with an explanation about when a feature is considered supported.
(Maybe) Add an exported function to gateway-api, which unifies the logic of supported features. This will improve the adoption of this GEP (as it will make it easier to implement), and will make things more consistent across implementations. Such function will return a list of supported features, given the ConformanceOptions.
Why this is needed:
I don't think it's clear how an implementation should programmatically decide which features it supports.
We have the ExemptFeatures field, which is straightforward - if a feature is in this list, it isn't supported by the implementation.
We also have the SkipTests field. If an extended feature is contained within the features list of the skipped test, then the implementation doesn't support it. (if this isn't the right logic, please correct me).
How can we programmatically decide about the core features?
Let's take HTTPRoute for example. Should an implementation assume that if it has at least one test in the suite, say HTTPRouteBackendRequestHeaderModifier, then it supports HTTPRoute?
@levikobi +1 to adding a util func within this repo to provide func GetSupportedFeatures(gatewaySuite suite.ConformanceOptions, skippedTests []suite.ConformanceTest) []gwapiv1.SupportedFeature
this allows the improvements in the GEP such as adding hyperlinks for the features to being implemented once in this repo and used by all downstream implementations
reg your comment around HTTPRoute , it represents all core conformance tests/features
associated with the HTTPRoute resource, so we'll need to modify the getSupportedFeatures func to make sure it doesnt get omitted if any extended features are removed
What would you like to be added:
ConformanceOptions
.Why this is needed:
I don't think it's clear how an implementation should programmatically decide which features it supports.
We have the
ExemptFeatures
field, which is straightforward - if a feature is in this list, it isn't supported by the implementation.We also have the
SkipTests
field. If an extended feature is contained within the features list of the skipped test, then the implementation doesn't support it. (if this isn't the right logic, please correct me).How can we programmatically decide about the core features?
Let's take
HTTPRoute
for example. Should an implementation assume that if it has at least one test in the suite, sayHTTPRouteBackendRequestHeaderModifier
, then it supportsHTTPRoute
?This issue came following this discussion
The text was updated successfully, but these errors were encountered: