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

chore: conformance profiles API version and channel #2062

Merged
merged 4 commits into from
Jun 5, 2023
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions geps/gep-1709.md
Original file line number Diff line number Diff line change
Expand Up @@ -253,6 +253,44 @@ move on to [certification](#certification) to report the results.
[go]:https://go.dev
[lib]:https://pkg.go.dev/sigs.k8s.io/[email protected]/conformance/utils/suite

### Gateway API version and channel

The certification is related to a specific API version and a specific channel,
therefore such information must be included in the final report.
At test suite setup time, the conformance profile
machinery gets all the CRDs with the field `.spec.group` equal to
`gateway.networking.k8s.io`, and for each of them checks the annotations
`gateway.networking.k8s.io/bundle-version` and
`gateway.networking.k8s.io/channel`. If there are `CRD`s with different
versions, the certification fails specifying that it's not possible to run the
tests as there are different Gateway API versions installed in the cluster. If
there are CRDs with different channels, the certification fails specifying
that it's not possible to run the tests as there are different Gateway API
channels installed in the cluster. If all the Gateway API `CRD`s have the same
version and the same channel, the tests can be run and the detected version
and channel will be set in the `GatewayAPIVersion` and `gatewayAPIChannel`
fields of the final report. Furthermore, the suite must run all the
experimental tests when the channel is `experimental`, and the related features
are enabled.

In addition to the `CRD`s version, the suite needs to check its version in
relation to the `CRD`s one. To do so, a new `.go` file containing the current
robscott marked this conversation as resolved.
Show resolved Hide resolved
Gateway API version is introduced in the project and compiled with the
conformance profile suite:

```go
const GatewayAPIVersion = "0.7.0"
```

At test suite setup time the conformance profile suite
checks the `CRD`s version and the suite version; if the two versions differ,
the certification fails.
A new generator will be introduced in the project to generate the
mlavacca marked this conversation as resolved.
Show resolved Hide resolved
aforementioned `.go` file starting from a VERSION file contained in the root
folder. Such a VERSION file contains the semver of the latest release and is
manually bumped at release time. The script hack/verify-all.sh will be updated
to ensure the generated `.go` file is up to date with the VERSION file.

### Certification

Implementations will be able to report their conformance testing results using
Expand Down Expand Up @@ -280,6 +318,7 @@ implementation:
- @acme/maintainers
date: "2023-02-28 20:29:41+00:00"
gatewayAPIVersion: v0.7.0
gatewayAPIChannel: standard
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean that most implementations would need to submit separate reports for each Gateway API Channel? I'm not sure we gain any value from that since the experimental channel is always a superset of the standard channel, but I may be missing something here.

I agree that the version of tests that are being run is critical though, so I'm glad that's included here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Since the experimental channel is a superset of the standard one, we could treat the report in the same way, which means being conformant to the experimental channel implies being conformant to the standard one. So that you just need to submit the experimental report to declare the standard conformance as well. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

That's kinda what I'm thinking - we may just want to recommend that implementations that support experimental features run conformance tests with experimental CRDs. I'm not sure that we need to actually state that in the report, but don't feel strongly either way.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I agree we need to add the proper documentation about this as well.

profiles:
- name: tcp
core:
Expand Down Expand Up @@ -360,6 +399,7 @@ implementation:
- @acme/maintainers
date: "2022-09-28 20:29:41+00:00"
gatewayAPIVersion: v0.6.2
gatewayAPIChannel: standard
profiles:
- name: tcp
core:
Expand Down Expand Up @@ -417,6 +457,7 @@ implementation:
- @acme/maintainers
date: "2022-08-28 20:29:41+00:00"
gatewayAPIVersion: v0.6.1
gatewayAPIChannel: standard
profiles:
- name: tcp
core:
Expand Down Expand Up @@ -465,6 +506,7 @@ implementation:
- @acme/maintainers
date: "2022-07-28 20:29:41+00:00"
gatewayAPIVersion: v0.6.0
gatewayAPIChannel: standard
profiles:
- name: http
core:
Expand Down