Spun off from bug 2018356, where a cluster went from a completed 4.7.34, partway to 4.8.17, and then was retargeted to 4.8.18. The kube-apiserver made it across to 4.8.17 during the first leg and set Upgradeable=False. The cluster-version operator noticed the 4.8.18 retarget and running its prechecks, used the most-recently-compeleted 4.7.34 as the base for its "is this a minor update?" checks [1]. And yes, 4.8.18 is a minor bump above 4.7.34.

A smarter CVO would have a status.versions check over in [2] that said something like:

kube-apiserver's status.versions[name=operator] has leveled on 4.8.17. That's a minor below my most recent completed version is 4.7.34, so I really don't care what kube-apiserver has to say about Upgradeable. It can't stop me from aiming for a new 4.8.z, and I'm not going to include its Upgradeable in ClusterVersion's Upgradeable.

That's still a bit off, because the one status.versions name we document is 'operator', and we require that to level after the whole component has rolled out the new version [3]. So operators like kube-apiserver can't just say "I'm a 4.8 operator, and I don't like how the cluster looks vs. what I know is coming in 4.9". They have to say "I'm a 4.8 operator, and my status.versions[name=operator] is also 4.8.z, so I can have opinions about whether my component can go to 4.9". If they have opinions with an older minor in status.versions[name=operator], the CVO will misattribute the Upgradeable option to the older minor, and might block patch-bumping retargets like we saw in bug 2018356.

Setting to medium because, while blocking a patch-level retarget is bad, not too many folks are doing patch-level retargets from the middle of a minor-bumping update.

And also in the retarget + Upgradeable space is bug 1802553, but that's about the CVO injecting a new Upgradeable condition on its own, while this bug is about aggregating ClusterOperator Upgradeable conditions, so I don't actually think there will be any code overlap between these two bugs.

[1]: https://github.com/openshift/cluster-version-operator/blob/c20e4d8a6cd8fe7f9cee5e05dc232f11c5b09ca8/pkg/payload/precondition/clusterversion/upgradeable.go#L114-L120
[2]: https://github.com/openshift/cluster-version-operator/blob/c20e4d8a6cd8fe7f9cee5e05dc232f11c5b09ca8/pkg/cvo/upgradeable.go#L179-L180
[3]: https://github.com/openshift/api/blob/c4970133b5ba3147da37ffd7cd8a18dd9bf052e0/config/v1/types_cluster_operator.go#L48