-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
4.15
-
None
Description of problem
When the cluster version operator has already accepted an update to 4.(y+1).z, it should accept retargets to 4.(y+1).z' even if ClusterVersion has Upgradeable=False (unless there are overrides, those are explicitly supposed to block patch updates). It currently blocks these retargets, which can make it hard for a cluster admin to say "hey, this update is stuck on a bug in 4.(y+1).z, and I want to retarget to 4.(y+1).z' to pick up the fix for that bug so the update can complete".
Spun out from evakhoni@redhat.com 's testing of OTA-861.
Version-Release number of selected component
Reproduced in a 4.15.35 CVO.
How reproducible
Reproduced in my first try, but I have not made additional attempts.
Steps to Reproduce
1. Install 4.y, e.g. with Cluster Bot launch 4.14.38 aws.
2. Request an update to a 4.(y+1).z:
a. oc adm upgrade channel candidate-4.15
b. oc adm upgrade --to 4.15.35
3. Wait until the update has been accepted...
$ oc adm upgrade | head -n1 info: An upgrade is in progress. Working towards 4.15.35: 10 of 873 done (1% complete
4. Inject an Upgradeable=False situation for testing:
$ oc -n openshift-config-managed patch configmap admin-gates --type json -p '[ {"op": "add", "path": "/data/ack-4.14-kube-1.29-api-removals-in-4.16", value: "testing"}]'
And after a minute or two, the CVO has noticed and set Upgradeable=False:
$ oc adm upgrade info: An upgrade is in progress. Working towards 4.15.35: 109 of 873 done (12% complete), waiting on etcd, kube-apiserver Upgradeable=False Reason: AdminAckRequired Message: testing Upstream: https://api.integration.openshift.com/api/upgrades_info/graph Channel: candidate-4.15 (available channels: candidate-4.15, candidate-4.16, fast-4.15, fast-4.16) Recommended updates: VERSION IMAGE 4.15.36 quay.io/openshift-release-dev/ocp-release@sha256:a8579cdecf1d45d33b5e88d6e1922df3037d05b09bcff7f08556b75898ab2f46
5. Request a patch-bumping retarget to 4.(y+1).z':
$ oc adm upgrade --allow-upgrade-with-warnings --to 4.15.36 warning: --allow-upgrade-with-warnings is bypassing: the cluster is already upgrading: Reason: ClusterOperatorsUpdating Message: Working towards 4.15.35: 109 of 873 done (12% complete), waiting on etcd, kube-apiserver Requested update to 4.15.36
6. Check the status of the retarget request: oc adm upgrade
Actual results
The retarget was rejected:
$ oc adm upgrade info: An upgrade is in progress. Working towards 4.15.35: 109 of 873 done (12% complete), waiting on etcd, kube-apiserver Upgradeable=False Reason: AdminAckRequired Message: testing ReleaseAccepted=False Reason: PreconditionChecks Message: Preconditions failed for payload loaded version="4.15.36" image="quay.io/openshift-release-dev/ocp-release@sha256:a8579cdecf1d45d33b5e88d6e1922df3037d05b09bcff7f08556b75898ab2f46": Precondition "ClusterVersionUpgradeable" failed because of "AdminAckRequired": testing Upstream: https://api.integration.openshift.com/api/upgrades_info/graph Channel: candidate-4.15 (available channels: candidate-4.15, candidate-4.16, fast-4.15, fast-4.16) Recommended updates: VERSION IMAGE 4.15.36 quay.io/openshift-release-dev/ocp-release@sha256:a8579cdecf1d45d33b5e88d6e1922df3037d05b09bcff7f08556b75898ab2f46
Expected results
The retarget should have been accepted, because 4.15.35 was already accepted, and 4.15.35 to 4.15.36 is a patch bump where Upgradeable=False is
Additional info
This GetCurrentVersion is looking in history for the most recent Completed entry. But for the Upgradeable precondition, we want to be looking in status.desired for the currently accepted entry, regardless of whether we've completed reconciling it or not.
- blocks
-
-
- New
-
- is cloned by
-
-
- New
-
- links to