Epic Goal

Enhance the ManagedClusterInfo synchronization to include upgradeable condition for the HostedCluster

Why is this important?

...

Scenarios

...

Acceptance Criteria Technical Notes

• ManagedClusterInfo includes upgradeable condition for hosted clusters versions

Technical Notes (see the full story document) :

• In standalone OCP, ClusterVersion has Upgradeable condition (True/False/Unknown).  While API docs leave some wiggle room, in practice, Upgradeable=False means the cluster thinks the cluster-admin needs to do something before the control plane can update from 4.y to 4.(y+1).  The CVO will reject spec.desiredUpdate requests that violate this constraint, unless the update is forced (we strongly warn against forcing).  We set the ReleaseAccepted condition False to report the rejection to the cluster admin (other issues like a failure to retrieve a release signature can also result in ReleaseAccepted=False, it's not just for Upgradeable=False violations).
• HyperShift's control-plane operator lifts the Upgradeable condition up from ClusterVersion into HostedControlPlane and renames it to ClusterVersionUpgradeable.  The HyperShift operator lifts it from HostedControlPlane to HostedCluster, still calling it ClusterVersionUpgradeable.  HyperShift also consumes the ClusterVersionUpgradeable condition when deciding if a HostedCluster is "progressing", although it's not all that clear to me why they do that, or what the user-experience impact is.
• Node skew constraint (version drift between nodes and control plane) is implemented in the standalone Kube API server operator via Upgradeable conditions since cluster-kube-apiserver-operator#1199.  That controller doesn't run in HyperShift though, so current HyperShift releases do not protect themselves from this skew constraint.  New HyperShift releases are growing protection against the installation of skew-violating old NodePools (or downgrading existing NodePools) in hypershift#5931.  It's unclear if they will add ClusterVersionUpgradeable controllers to keep the HostedCluster from outpacing existing NodePools or not.  There are support-risks either way.
• This makes for a pretty convoluted experience for folks trying to consume the ClusterVersion and HostedCluster APIs to drive updates.  Trevor's long-term goal is to fold (ClusterVersion)Upgradeable in as a conditional update risk.  oc#1907 landed code to do that client-side, which went GA in 4.20 with oc adm upgrade recommend.  OTA-1452 is tracking the server-side move, but the timeline for delivering that GA is unclear (no current customers or other priority influencers are pushing for this change.  If you want it, Trevor recommends opening an RFE ticket against the updates component asking for it, and explaining the value you see it delivering for your use case).

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

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 - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.
• Considerations were made for Extended Update Support (EUS)