-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
4.19
-
None
-
2
-
False
-
spawn off from OCPBUGS-8259 testing results, and from comments by Trevor
whenever .spec.desiredUpdate.architecture Multi is applied, cvo is fetching a release named as its own version from upgrade graph (.spec.upstream) while requesting arch=multi from the graph. cvo however does not check the release architecture being replied by the graph, and blindly assumes it being the correct multi-arch version, without checking for neither the lack of "release.openshift.io/architecture": "multi" in the upgrade graph reply, nor if the payload digest privided by the graph a single-arch version.
Version-Release number of selected component (if applicable):
all versions since 4.13 where transition to multi arch by the means of setting desiredUpdate.architecture were introduced.
How reproducible:
100%
Steps to Reproduce:
1. provide an upgrade graph where current cluster version is available, but no multi-arch payload is available, such as the graph generated by the release controller at amd64.ocp.releases.ci.openshift.org/graph
$ oc patch clusterversion/version --patch '{"spec":{"upstream":"https://amd64.ocp.releases.ci.openshift.org/graph"}}' --type=merge
2. verify that cvo is able to retrieve its own version from the graph, by observing RetrievedUpdates=True
$ oc get clusterversion/version -o jsonpath='{.status.conditions[?(@.type==\"RetrievedUpdates\")].status}'
3. apply .spec.desiredUpdate.architecture: Multi, for example by using --to-multi-arch flag
$ oc adm upgrade --to-multi-arch
4. observe the target being accepted by cvo and progressing
Actual results:
cvo is trying to progress to any version returned by the graph, as long as its "version" value match
Expected results:
cvo is either/both checking for "release.openshift.io/architecture": "multi" in the reply from the graph, or verifying the payload to be an actual multi (manifest.list.v2) type