OCPNODE-3611: manifests.rhel/0000_90_openshift-cluster-image-policy: Drop TechPreviewNoUpgrade limitation #82
Conversation
…ewNoUpgrade limitation Now that ClusterImagePolicy is v1 and in the default feature set, we can remove the annotation that limites the openshift ClusterImagePolicy to the TechPreviewNoUpgrade feature set. No CI impact is expected, because even 4.y.z release-controller jobs [1] like 4.19.8 -> 4.19.9 [2] use imported-into-CI-registry versions of the target release like registry.ci.openshift.org/ocp/release:4.19.9 [3]. But it sets us up for being able to drop OpenPGP/GPG signature verification in future releases, and avoids the risk that a 4.20 customer creates their own openshift ClusterImagePolicy and the resulting de-conflicting guards we'd need on 4.20-to-4.21 updates. [1]: https://amd64.ocp.releases.ci.openshift.org/releasestream/4-stable/release/4.19.9 [2]: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/release-openshift-origin-installer-e2e-aws-upgrade/1956054636976672768 [3]: https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/release-openshift-origin-installer-e2e-aws-upgrade/1956054636976672768/artifacts/e2e-aws-upgrade/clusterversion.json
openshift-ci-robot
added
the
jira/valid-reference
|
@wking: This pull request references OCPNODE-3611 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. 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. |
|
/retest-required |
jupierce
added
the
acknowledge-critical-fixes-only
|
/lgtm |
openshift-ci
bot
added
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jupierce, 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
|
@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. |
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
…-openshift-cip"" This reverts commit 7a5dcee. This one has taken us some time: * 2025-08-27, 94f7582, openshift#82 was our first attempt at enabling the ClusterImagePolicy. * ...but it tripped up the origin test suite, so it was reverted in 2025-08-28, c40e7b9, openshift#83. * Qi then hardened the test suite with openshift/origin@d3af51e4acb (not fail upgrade checks if all nodes are ready, 2025-09-29, openshift/origin#30318) and openshift/origin@2fd0d8e242 (Upgrade test add 2min grace period allow non-drain updates to complete, 2025-11-12, openshift/origin#30480). * With the tougher CI in place, we tried a second time with 2025-11-17, 1f89a67, openshift#85. * ...but still tripped up origin, with runs like [1] taking 2.25m (more than the 2m grace period): I1119 17:26:21.890667 1511 upgrade.go:629] Waiting on pools to be upgraded I1119 17:26:21.939178 1511 upgrade.go:792] Pool master is still reporting (Updated: false, Updating: true, Degraded: false) I1119 17:26:21.939259 1511 upgrade.go:666] Invariant violation detected: master pool requires update but nodes not ready. Waiting up to 2m0s for non-draining updates to complete I1119 17:26:31.984116 1511 upgrade.go:792] Pool master is still reporting (Updated: false, Updating: true, Degraded: false) ... I1119 17:28:21.981438 1511 upgrade.go:792] Pool master is still reporting (Updated: false, Updating: true, Degraded: false) I1119 17:28:21.981514 1511 upgrade.go:673] Invariant violation detected: the "master" pool should be updated before the CVO reports available at the new version and: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/periodic-ci-openshift-release-master-ci-4.21-upgrade-from-stable-4.20-e2e-gcp-ovn-rt-upgrade/1991158541779472384/artifacts/e2e-gcp-ovn-rt-upgrade/gather-extra/artifacts/inspect/cluster-scoped-resources/machineconfiguration.openshift.io/machineconfigpools/master.yaml | yaml2json | jq -r '.status.conditions[] | select(.type == "Updating") | .lastTransitionTime + " " + .status' 2025-11-19T17:28:36Z False 28:36 - 26:21 = 135s = 2.25m, which overshot the 2m grace period. The second attempt was reverted in 7a5dcee, openshift#87. * Qi then hardened the test suite further with openshift/origin@c17e560263 (Update grace period for cluster upgrade to 10 minutes, 2025-11-19, #openshift/origin#30506). * This commit is taking a third attempt at enabling the ClusterImagePolicy. [1]: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-release-master-ci-4.21-upgrade-from-stable-4.20-e2e-gcp-ovn-rt-upgrade/1991158541779472384
3 participants
Now that ClusterImagePolicy is v1 and in the default feature set, we can remove the annotation that limites the openshift ClusterImagePolicy to the TechPreviewNoUpgrade feature set. No CI impact is expected, because even 4.y.z release-controller jobs like 4.19.8 -> 4.19.9 use imported-into-CI-registry versions of the target release like registry.ci.openshift.org/ocp/release:4.19.9. But it sets us up for being able to drop OpenPGP/GPG signature verification in future releases, and avoids the risk that a 4.20 customer creates their own openshift ClusterImagePolicy and the resulting de-conflicting guards we'd need on 4.20-to-4.21 updates.