Enhancing GatewayClass Status API - Conformance features #2108
Replies: 2 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
-
|
I think that we should just use the same structs as we do in the conformance profile object - this makes the conformance report the same whether it's submitted to the project for validation, or reviewed in the GatewayClass by the user. Plus it's only one place to update. |
Beta Was this translation helpful? Give feedback.
-
|
On one hand one place to update seems appealing. OTOH I think the profiles now are a bit too structured for a status object. As a user I do not really care about additional metadata the conformanceProfiles apis include now. What I want is to see if my gwc support a feature that I want to use. Also for the webhook, does the webhook need to care about whether it is core/extended or something else? Not sure I have the answer in my head, but for sure I think the metadata is not needed. The question is should we reuse the ProfileReport or have something lighter. I am open to debate |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The current GatewayClassStatus API is only used to store conditions the controller publishes.
With the evolution of the Conformance tests suite and features, we want to;
Stating this discussion to gather feedback and thoughts before writing a GEP. I will start with a few ideas I've already discussed with some folks.
This is partially related to #1804
Note: I am starting a separate discussion about another enhancement to represent policies/extensions the GWC support.
Beta Was this translation helpful? Give feedback.
All reactions