Moving the bug https://bugzilla.redhat.com/show_bug.cgi?id=1802553 to this Jira card

Currently we had a customer that triggered the upgrade from 4.1.27 to 4.3, having intermediate versions on 4.2 in partial state. We have asked for details of the CVO from the customer to understand better the procedure taken, but we might need to implement a way to either stop the upgrade in case customer makes a mistake or block the upgrade if the customer changes the channel on the console to a version which the upgrade does not support, like in this case.

As per https://github.com/openshift/enhancements/blob/master/enhancements/update/eus-upgrades-mvp.md#ota---inhibit-minor-version-upgrades-when-an-upgrade-is-in-progress

OTA - Inhibit minor version upgrades when an upgrade is in progress

We should inhibit minor version upgrades via Upgradeable=False whenever an existing upgrade is in progress. This prevents retargetting of upgrades before we've reached a safe point.

Imagine:

Be running 4.6.z.
Request an update to 4.7.z'.
CVO begins updating to 4.7.z'.
CVO requests recommended updates from 4.7.z', and hears about 4.8.z".
User accepts recommended update to 4.8.z" before the 4.7.z' OLM operator had come out to check its children's max versions against 4.8 and set Upgradeable=False.
Cluster core hits 4.8.z" and some OLM operators fail on compat violations.

This should not inhibit further z-stream upgrades, but we should be sure that we catch the case of 4.6.z to 4.7.z to 4.7.z+n to 4.8.z whenever 4.7.z was not marked as Complete.

Update:

Eventually, the output of this card:

• y-then-y: blocked (originally required in this card description).
• z-then-y: blocked (not originally required in this card description but during the implementation we think it is good to have).
• y-then-z or z-then-z: accepted because we need to always allow z-upgrade to include fixes.