Epic Goal

• Enable a control plane upgrade by updating the version of a given cluster's control plane in the user-facing cluster resource.
• Upgrades should result in minimal/no disruption to the guest cluster's API.
• An upgrade of the control plane should be independent of worker node upgrades.

Why is this important?

• It should be possible to manage the lifecycle of hosted control plane clusters via the user facing API
• Hosted control plane clusters should be as long-lived as their self-hosted counterparts.
• It should be easy to apply embargoed updates in a managed scenario. 

Scenarios

1. Upgrade a hosted control plane cluster by modifying its CR

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. …

Open questions::

1. Will we allow downgrades?

References

https://github.com/openshift/hypershift/pull/81 

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>