OCPBUGS-41642: config/v1/types_cluster_version: Add v4.17 capability set #2023
Conversation
|
Hello @wking! Some important instructions when contributing to openshift/api: |
openshift-ci
bot
added
the
size/S
|
/Jira cherrypick OCPBUGS-41111 |
|
@wking: Jira Issue OCPBUGS-41111 has been cloned as Jira Issue OCPBUGS-41642. Will retitle bug to link to clone. In 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
changed the title
openshift-ci-robot
added
jira/severity-important
|
@wking: This pull request references Jira Issue OCPBUGS-41642, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In 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. |
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
wking
force-pushed
the
4.17-cluster-version-capability-sets
branch
from
35023e0
to
da9cfc5
Compare
openshift-ci
bot
added
size/M
|
/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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
sdodson
added
cherry-pick-approved
|
@wking: all tests passed! Full PR test history. Your PR dashboard. 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 kubernetes-sigs/prow repository. I understand the commands that are listed here. |
openshift-merge-bot
bot
merged commit 0a88001
into
openshift:release-4.17
|
@wking: Jira Issue OCPBUGS-41642: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-41642 has been moved to the MODIFIED state. In 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], and a backport-ish of 6abe8bb (vendor: Update openshift/api to pick up v4.17 and v4.18 capability sets, 2024-09-11, $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ go mod tidy $ go mod vendor $ git add -A go.* vendor all using: $ go version go version go1.22.2 linux/amd64 where GOPROXY=direct avoids a caching delay [2]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. [1]: openshift/api#2023 [2]: https://proxy.golang.org/
Catching up with [1], and a backport-ish of 6abe8bb (vendor: Update openshift/api to pick up v4.17 and v4.18 capability sets, 2024-09-11, openshift#1086). Generated with: $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ go mod tidy $ go mod vendor $ git add -A go.* vendor all using: $ go version go version go1.22.2 linux/amd64 where GOPROXY=direct avoids a caching delay [2]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. [1]: openshift/api#2023 [2]: https://proxy.golang.org/
Catching up with [1], and a backport-ish of 45ab914729 (vendor: Update openshift/api to pick up the v4.17 capability sets, 2024-09-11, openshift#1875), which may or may not land due to conflicts with the Kubernetes rebase [2]. Generated with: $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ go mod tidy $ go mod vendor $ git add -A go.* vendor all using: $ go version go version go1.22.2 linux/amd64 where GOPROXY=direct avoids a caching delay [3]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. This addresses [4]: $ 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#2023 [2]: openshift#1875 (comment) [3]: https://proxy.golang.org/ [4]: https://issues.redhat.com/browse/OCPBUGS-41111
Catching up with [1], and a backport-ish of 9d1f82a (vendor: Update openshift/api to pick up v4.17 and v4.18 capability sets, 2024-09-12, openshift#9002). Generated with: $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ 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.22.2 linux/amd64 where GOPROXY=direct avoids a caching delay [2]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. This will allow users to use the new capability sets in their install-config YAML. [1]: openshift/api#2023 [2]: https://proxy.golang.org/
|
[ART PR BUILD NOTIFIER] Distgit: ose-cluster-config-api |
Catching up with [1], and a backport-ish of 9d1f82a (vendor: Update openshift/api to pick up v4.17 and v4.18 capability sets, 2024-09-12, openshift#9002). Generated with: $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ 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 where GOPROXY=direct avoids a caching delay [2]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. This will allow users to use the new capability sets in their install-config YAML. [1]: openshift/api#2023 [2]: https://proxy.golang.org/
Catching up with [1], and a backport-ish of 9d1f82a (vendor: Update openshift/api to pick up v4.17 and v4.18 capability sets, 2024-09-12, openshift#9002). Generated with: $ GOPROXY=direct go get github.com/openshift/api@release-4.17 $ 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 where GOPROXY=direct avoids a caching delay [2]: I committed a new change (or released a new version) to a repository, why isn't it showing up when I run go get -u or go list -m --versions? In order to improve our services' caching and serving latencies, new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue. This will allow users to use the new capability sets in their install-config YAML. [1]: openshift/api#2023 [2]: https://proxy.golang.org/
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 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 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) #2022 to
release-4.17.