-
Notifications
You must be signed in to change notification settings - Fork 213
CNF-9385: add ImageRegistry capability #950
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
Conversation
|
@qJkee: This pull request references CNF-5647 which is a valid jira issue. 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 kubernetes/test-infra repository. |
|
Skipping CI for Draft Pull Request. |
|
@qJkee: This pull request references CNF-9385 which is a valid jira issue. 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 kubernetes/test-infra repository. |
go get -u github.com/openshift/api@master go mod tidy go mod vendor git add -A go.* vendor
|
@qJkee: This pull request references CNF-9385 which is a valid jira issue. 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 kubernetes/test-infra repository. |
update tests with new capabilities brought by new version of openshift/api package
|
/test e2e-agnostic-ovn e2e-agnostic-operator |
|
/cc |
wking
left a comment
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 upgrade-out-of-change job will never pass, as the incoming old CRD's restrictive status.capabilities.knownCapabilities enum rejects the CVO's attempt to write MachineAPI and the other new caps. Which blocks the CVO from setting other status properties, including the ones that point out that the release transition has completed.
/override ci/prow/e2e-agnostic-ovn-upgrade-out-of-change
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qJkee, 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 |
|
@wking: Overrode contexts on behalf of wking: ci/prow/e2e-agnostic-ovn-upgrade-out-of-change 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 kubernetes/test-infra repository. |
|
@qJkee: 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/test-infra repository. I understand the commands that are listed here. |
The capability is new in 4.14, via openshift/api@d557f9784b (WRKLDS-728: Make Build and DeploymentConfig API optional through capabilities, 2023-05-24, openshift/api#1462) and ba3aeb9 (vendor: bump openshift/api, 2023-08-02, openshift#950). But as pointed out in [1], 4.14 releases do not declare any manifests as linked to the new capability: $ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.14.0-rc.5-x86_64 Extracted release payload from digest sha256:042899f17f33259ed9f2cfc179930af283733455720f72ea3483fd1905f9b301 created at 2023-10-10T18:00:08Z $ grep -ohr 'capability.openshift.io/name:.*' manifests | sort | uniq capability.openshift.io/name: baremetal capability.openshift.io/name: Console capability.openshift.io/name: CSISnapshot capability.openshift.io/name: ImageRegistry capability.openshift.io/name: Insights capability.openshift.io/name: MachineAPI capability.openshift.io/name: marketplace capability.openshift.io/name: NodeTuning capability.openshift.io/name: openshift-samples capability.openshift.io/name: Storage That means our existing logic to compare reconciled-manifest requirements for detecting the need to implicitly enable capabilities breaks down. In this commit, I'm teaching the outgoing 4.13 CVO that all 4.13 clusters have the DeploymentConfig capability enabled (even if it is not declared by a ClusterVersion capability in 4.13), so that capability needs to persist into 4.14 releases, to avoid surprising admins by dropping functionality. Folks who do want to drop DeploymentConfig functionality will need to perform fresh installs with 4.14 or later, because capabilities cannot be uninstalled [2]. [1]: https://issues.redhat.com/browse/OCPBUGS-20321 [2]: https://github.com/openshift/enhancements/blob/d2edd51b600c5490eaa3650aac3b45a0bff5b3d5/enhancements/installer/component-selection.md#capabilities-cannot-be-uninstalled
Bump openshift/api to bring new cluster capability ImageRegistry