Skip to content
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

Merged
merged 5 commits into from
Mar 28, 2024

Conversation

mlavacca
Copy link
Member

@mlavacca mlavacca commented Mar 13, 2024

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?:

The Experimental Conformance test suite has been promoted to standard. Furthermore, the `ConformanceReport` API has been promoted to `v1`.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. area/conformance cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Mar 13, 2024
@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 13, 2024
@mlavacca
Copy link
Member Author

/cc @shaneutt @robscott @youngnick

@mlavacca
Copy link
Member Author

/ok-to-test

@k8s-ci-robot k8s-ci-robot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Mar 13, 2024
@k8s-ci-robot k8s-ci-robot removed the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 13, 2024
conformance/conformance_test.go Outdated Show resolved Hide resolved
conformance/utils/flags/flags.go Show resolved Hide resolved
conformance/utils/suite/conformance-test.go Outdated Show resolved Hide resolved
conformance/utils/suite/conformance-test.go Outdated Show resolved Hide resolved
@@ -67,7 +67,9 @@ var (
SupportReferenceGrant,
SupportHTTPRoute,
),
ExtendedFeatures: HTTPRouteExtendedFeatures,
ExtendedFeatures: sets.New[SupportedFeature]().
Insert(GatewayExtendedFeatures.UnsortedList()...).
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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?

#2845

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, WDYT?

Copy link
Member

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.

Copy link
Member

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".

Copy link
Contributor

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

Copy link
Member

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:

  1. 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.
  2. 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.

Copy link
Member

@robscott robscott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mlavacca!

conformance/apis/v1beta1/doc.go Outdated Show resolved Hide resolved
conformance/utils/flags/flags.go Outdated Show resolved Hide resolved
conformance/utils/suite/conformance.go Outdated Show resolved Hide resolved
conformance/utils/suite/conformance_test.go Outdated Show resolved Hide resolved
conformance/utils/suite/suite.go Outdated Show resolved Hide resolved
conformance/utils/suite/suite.go Show resolved Hide resolved
conformance/apis/v1beta1/profilereport.go Outdated Show resolved Hide resolved
Copy link
Member

@shaneutt shaneutt left a 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

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 17, 2024
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 26, 2024
@shaneutt shaneutt requested a review from robscott March 27, 2024 11:03
@youngnick
Copy link
Contributor

LGTM once the merge conflict is fixed.

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

mlavacca and others added 5 commits March 28, 2024 14:12
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>
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 28, 2024
@dprotaso
Copy link
Contributor

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 28, 2024
@k8s-ci-robot k8s-ci-robot merged commit 204abaf into kubernetes-sigs:main Mar 28, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/conformance cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Promote the experimental conformance test suite to standard
7 participants