Epic Goal

• Inhibit upgrades to next minor version whenever supported client version skew would be triggered

Why is this important

• As part of the EUS-to-EUS work we're proposing upgrades where worker pools are paused. In order to prevent unsupported version skew between API and Kubelet we must not allow upgrades when we're at the maximum allowed version skew. ie: API at 1.22 and the presents of one or more kublets at 1.20 in the cluster.

Scenarios

1. Paused worker MachineConfigPool
2. Upgrade from 4.8 to 4.9 to 4.10. Ensure kube-apiserver is Upgradeable=False with a reason that clearly indicates presence of kubelets at maximum version skew
3. Unpause worker MachineConfigPool, validate kube-apiserver transitions to Upgradeable=True

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. CI job which added paused pools upgrades and would need to add checking for Upgradeable=False at the bounds
   https://github.com/openshift/release/pull/15939/files#diff-1a46129e809990d7d8a81a52a2a48bc8258fae24f171dccb14d3bf00301a3b35R167

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>