OCPBUGS-41111: config/v1/types_cluster_version: Add v4.17 and v4.18 capability sets#2022
Conversation
|
Hello @wking! Some important instructions when contributing to openshift/api: |
openshift-ci-robot
added
jira/severity-important
|
@wking: This pull request references Jira Issue OCPBUGS-41111, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
Requesting review from QA contact: The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
added
the
size/M
This is a synonym for v4.16, because there have not been capability-recommendation changes since that release. 4.17 is about to go Generally Available, which means v4.17 will always be a synonym for v4.16. I think defining synonym capability sets is busywork that takes developer time without adding customer value, but [1] points out that so far every 4.y release has had a v4.y capability set string associated with it, and folks might find adjustments to that pattern surprising. I'm declaring the v4.17 set to continue the existing set-for-each-4.y pattern (and breaking the set-for-each-4.y-with-a-different-default pattern) to unblock 4.17's GA, but we may revisit this approach in the future with more lead time. This commit backports (without v4.18) [2] to release-4.17. [1]: https://issues.redhat.com/browse/OCPBUGS-41111 [2]: openshift#2022
This is a synonym for v4.16, because there have not been capability-recommendation changes since that release. 4.17 is about to go Generally Available, which means v4.17 will always be a synonym for v4.16. I think defining synonym capability sets is busywork that takes developer time without adding customer value, but [1] points out that so far every 4.y release has had a v4.y capability set string associated with it, and folks might find adjustments to that pattern surprising. I'm declaring the v4.17 set to continue the existing set-for-each-4.y pattern (and breaking the set-for-each-4.y-with-a-different-default pattern) to unblock 4.17's GA, but we may revisit this approach in the future with more lead time. This commit backports (without v4.18) [2] to release-4.17. [1]: https://issues.redhat.com/browse/OCPBUGS-41111 [2]: openshift#2022
These are both synonyms for v4.16, because there have not been capability-recommendation changes since that release. 4.17 is about to go Generally Available, which means v4.17 will always be a synonym for v4.16. v4.18 may or may not evolve before 4.18 goes GA. I think defining synonym capability sets is busywork that takes developer time without adding customer value, but [1] points out that so far every 4.y release has had a v4.y capability set string associated with it, and folks might find adjustments to that pattern surprising. I'm declaring sets for our next two 4.y here to continue the existing set-for-each-4.y pattern (and breaking the set-for-each-4.y-with-a-different-default pattern) to unblock 4.17's GA, but we may revisit this approach in the future with more lead time. [1]: https://issues.redhat.com/browse/OCPBUGS-41111
wking
force-pushed
the
4.17-and-4.18-cluster-version-capability-sets
branch
from
eeb1bf2 to
67e03da
Compare
|
@wking: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This is a synonym for v4.16, because there have not been capability-recommendation changes since that release. 4.17 is about to go Generally Available, which means v4.17 will always be a synonym for v4.16. I think defining synonym capability sets is busywork that takes developer time without adding customer value, but [1] points out that so far every 4.y release has had a v4.y capability set string associated with it, and folks might find adjustments to that pattern surprising. I'm declaring the v4.17 set to continue the existing set-for-each-4.y pattern (and breaking the set-for-each-4.y-with-a-different-default pattern) to unblock 4.17's GA, but we may revisit this approach in the future with more lead time. This commit backports (without v4.18) [2] to release-4.17. [1]: https://issues.redhat.com/browse/OCPBUGS-41111 [2]: openshift#2022
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
@wking: Jira Issue OCPBUGS-41111: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-41111 has been moved to the MODIFIED state. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
Catching up with [1]. Generated with: $ go get github.com/openshift/api@master $ go mod tidy $ go mod vendor $ git add -A go.* vendor all using: $ go version go version go1.22.2 linux/amd64 [1]: openshift/api#2022
|
[ART PR BUILD NOTIFIER] Distgit: ose-cluster-config-api |
Catching up with [1]. Generated with:
$ go get github.com/openshift/api@master
$ go mod tidy
$ go mod vendor
$ git add -A go.* vendor
all using:
$ go version
go version go1.22.2 linux/amd64
This addresses [2]:
$ cat v4.17-basecap.yaml
---
apiVersion: v1
platform:
gcp:
foo: bar
capabilities:
baselineCapabilitySet: v4.17
$ ./oc adm release extract --install-config v4.17-basecap.yaml --included --credentials-requests --from quay.io/openshift-release-dev/ocp-release:4.17.0-rc.1-x86_64 --to /tmp/test
error: unrecognized baselineCapabilitySet "v4.17"
because pkg/cli/admin/release/extract_tools.go uses the vendored
openshift/api/config/v1 to unpack capabilities.
[1]: openshift/api#2022
[2]: https://issues.redhat.com/browse/OCPBUGS-41111
Catching up with [1]. Generated with: $ go get github.com/openshift/api@master $ go mod tidy $ go mod vendor $ go generate ./pkg/types/installconfig.go $ git add -A go.* vendor data/data/install.openshift.io_installconfigs.yaml all using: $ go version go version go1.23.1 linux/amd64 This will allow users to use the new capability sets in their install-config YAML. [1]: openshift/api#2022
4 participants
These are both synonyms for v4.16, because there have not been capability-recommendation changes since that release. 4.17 is about to go Generally Available, which means v4.17 will always be a synonym for v4.16. v4.18 may or may not evolve before 4.18 goes GA. I think defining synonym capability sets is busywork that takes developer time without adding customer value, but OCPBUGS-41111 points out that so far every 4.y release has had a v4.y capability set string associated with it, and folks might find adjustments to that pattern surprising. I'm declaring sets for our next two 4.y here to continue the existing set-for-each-4.y pattern (and breaking the set-for-each-4.y-with-a-different-default pattern) to unblock 4.17's GA, but we may revisit this approach in the future with more lead time.