Goal

• Report Hosted Control Plane status independently from CVO
• Determine Hosted Control Plane specific upgradeability status
• Maintain API users ability to make use of
  • ClusterVersionProgress
  • ClusterVersionUpgradeable
  • ClusterVersionAvailable

Why is this important?

• Assess Control Plane upgradeable conditions when no NodePools exist or they are scaled down to zero
• Simplify gathering whether a Hosted Cluster's Control Plane is upgradeable
• Ensure Control Plane components upgrade does not stall due to cluster Operator health state

Scenarios

1. Upgrading a Hosted Control Plane in the absence of worker nodes
2. Assessing the upgradeability of a Hosted Control Plane that has unhealthy Cluster Operators in the customer side

Acceptance Criteria

• Dev - SD-ADR approval
• CI - MUST be running successfully with tests automated (probably the simplest is with zero worker nodes)
• QE - covered in Polarion test plan and tests implemented
• Release Technical Enablement - Documentation coverage

Dependencies (internal and external)

1. SD-ADR-0230 is approved

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Technical Enablement <link to Feature Enablement Presentation>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Enhancement merged: <link to meaningful PR or GitHub Issue>
• 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>