-
Notifications
You must be signed in to change notification settings - Fork 458
OCPBUGS-64822: Implement upgrade blocking for conflicting ClusterImagePolicy named "openshift" #5397
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
OCPBUGS-64822: Implement upgrade blocking for conflicting ClusterImagePolicy named "openshift" #5397
Conversation
…openshift" Added logic to check if the resource is customer-created and update the cluster operator status Upgradeable=False accordingly. This prevents upgrades when a conflicting policy is detected. This check needs to be backported to 4.20.z as we plan to GA `openshift` ClusterImagePolicy in 4.21. Signed-off-by: Qi Wang <[email protected]>
793ffbe to
87bdf1f
Compare
|
/test unit |
| if configNode.Spec.CgroupMode == configv1.CgroupModeV1 { | ||
| coStatusCondition.Status = configv1.ConditionFalse | ||
| coStatusCondition.Reason = "ClusterOnCgroupV1" | ||
| coStatusCondition.Message = "Cluster is using deprecated cgroup v1 and is not upgradable. Please update the `CgroupMode` in the `nodes.config.openshift.io` object to 'v2'. Once upgraded, the cluster cannot be changed back to cgroup v1" |
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.
cgroup v1 was removed in 4.19. I dunno how this block still exists in the 4.20 controller? I'm also surprised that the API repo's dev branch still includes CgroupModeV1. Not something you need to deal with; I was just looking at this block while wondering how concerned I was about this function's "last complaint wins" competition over a single coStatusCondition.
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.
@sairameshv FYI
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.
Yes, it totally makes sense to remove this dead code from the clusters > 4.19
Created a PR here for the same
This can be back-ported to release-4.20 branch as well
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.
Seems like MCO maintainers may want to revisit how they maintain this function to prune obsolete content. But the code you're adding is just in the 4.20 branch, so there will be no dev-branch addition that needs future pruning. And the last-complaint-wins approach you're using follows existing precedent for DegradedPool and InterruptedBuild that will continue on in the dev branch. And the guard logic itself looks good to me. So:
/lgtm
|
@QiWang19: This pull request references Jira Issue OCPBUGS-64822, 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. |
|
/jira refresh |
|
@QiWang19: This pull request references Jira Issue OCPBUGS-64822, which is valid. The bug has been moved to the POST state. 7 validation(s) were run on this bug
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. |
|
/verified by @QiWang19 on cluster |
|
@QiWang19: This PR has been marked as verified by 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. |
|
/assign @isabella-janssen |
isabella-janssen
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.
/approve
These changes look fair to me & have been verified.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: isabella-janssen, QiWang19, 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 |
|
/label backport-risk-assessed This change should be a safe backport. |
|
@QiWang19: The following test failed, say
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. |
|
/retest-required |
f353bfb
into
openshift:release-4.20
|
@QiWang19: Jira Issue Verification Checks: Jira Issue OCPBUGS-64822 Jira Issue OCPBUGS-64822 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓 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. |
- What I did
Added logic to check if the resource
openshiftis customer-created and update the cluster operator status Upgradeable=False accordingly. TheopenshiftCIP is cluster-managed reserved for release payload verification. This prevents upgrades when a conflicting policy is detected.This check needs to be backported to 4.20.z as we plan to GA
openshiftClusterImagePolicy (openshift/cluster-update-keys#85) in 4.21.- How to verify it
Upgradeable=False- Description for the changelog
Implement upgrade blocking for conflicting ClusterImagePolicy named "openshift"