-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental conformance promotion to standard #2868
Experimental conformance promotion to standard #2868
Conversation
/ok-to-test |
aa4e92b
to
68233ac
Compare
@@ -67,7 +67,9 @@ var ( | |||
SupportReferenceGrant, | |||
SupportHTTPRoute, | |||
), | |||
ExtendedFeatures: HTTPRouteExtendedFeatures, | |||
ExtendedFeatures: sets.New[SupportedFeature](). | |||
Insert(GatewayExtendedFeatures.UnsortedList()...). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding Gateway Extended Features to HTTP profile seems off
I could imagine there being an Extended feature that has nothing to do with HTTPRoute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current Gateway API extended features are GatewayPort8080
and GatewayStaticAddresses
. I think both are totally relevant to the HTTP profile and should be included here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woud gateway infrastructure be something that we want in the HTTP profile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @dprotaso's concerns are actually the same as mine - how do we avoid exponential growth in terms of profiles here?
For example, you could imagine multiples of the following:
mesh+gateway * each unique combination of route types (by protocol, layer, or all) * core + extended
One option would be to start exclusively with profiles for core support of GA resources in v1.1 (Gateway, HTTPRoute, and GRPCRoute) - I think Gateway is inseparable from GatewayClass so it's probably fine to merge those together. Maybe to take that one step further, does that just become another way to express the SupportHTTPRoute
supported feature?
To be clear, I'm very excited about the updated conformance reporting which I think is what the vast majority of this PR is about, I'm just worried that if we're not careful with the profiles terminology here, we'll end up with an unmaintainable number of profile names alongside an ever-expanding set of feature names that could become overly confusing when layered on top of each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a reminder, the idea of profiles is that they're just convenient groupings of features, e.g.:
Individual Tests
|_
SupportedFeatures
|_
ConformanceProfiles
The profiles are meant to cover the most common combinations of feature groupings, providing high level composability for implementations to subscribe to. This has been documented as the intent for over a year, and the currently expected profiles are common ones such as "HTTP", "Mesh", "L4", e.t.c.
I wonder if trying to change this now (especially as we were just about to go standard with it) would just be treating a symptom of a problem no where near the source of the problem, like how pain in us humans can radiate so we feel it somewhere it is not: perhaps Gateway APIs scope is way too large, and we're trying to cover too many things as a single project. So perhaps it is not "there's potential for too many conformance profiles" but instead "there's too many things we're trying to support as a single sub-project".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @shaneutt thanks for the clarification. I'm good with this then. I also missed the fact that extended features need to be activated with the SupportedFeatures
flag when running the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, gotcha. There are a couple other things to keep in mind here too:
- Network Policy is (without any complaints thus far) using this as well and hoping to standardize on it once we do, so if we make any last minute large changes to the GEP this effects them as well.
- Unlike the APIs or regular Go code, this doesn't have direct user implications. So if we do find in time we need a revision because we start experiencing some real world problems, it's not as hard to make some backwards incompatible changes.
Since this PR is simply the last PR implementing the existing GEP, because we're 2 weeks before release, and given the above context I think we should move forward as is and judge this based on it's adherence to the current GEP, and if needed make grander changes to the GEP itself separately.
5e62da6
to
4ea1e10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mlavacca!
458eabb
to
39fb7f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the comments already provided, looks good 👍
/approve
39fb7f1
to
266a224
Compare
LGTM once the merge conflict is fixed. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, mlavacca, shaneutt, tao12345666333 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com> Co-authored-by: Dave Protasowski <dprotaso@gmail.com>
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
Signed-off-by: Mattia Lavacca <lavacca.mattia@gmail.com>
266a224
to
1fd59a4
Compare
/lgtm |
What type of PR is this?
/area conformance
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #2851
Does this PR introduce a user-facing change?: