OCP/Telco Definition of Done
https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde
Epic Template descriptions and documentation.
https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit
ACM-wide Product Requirements (Top-level Epics)
https://docs.google.com/document/d/1uIp6nS2QZ766UFuZBaC9USs8dW_I5wVdtYF9sUObYKg/edit

*<--- Cut-n-Paste the entire contents of this description into your new
Epic --->*

Epic Goal

Support upgrading HCP clusters created outside of ACM and then imported into ACM to be managed.

Currently there is no easy way to do this because we can't update the ClusterVersion on HCP clusters directly. HCP upgrades can only be initiated through the HostedCluster CR but in this case we don't know where the HostedCluster CR is located.

Once feature https://issues.redhat.com/browse/ACM-14714 is implemented, we could use the following flow.

1. From ACM, set the HostedCluster's spec.channel if not set. This update action should be targeted to the managed MCE cluster via cluster-proxy.
2. The ACM console should read the HostedCluster's available and recommended updates from the HostedCluster's status and present it in the available updates list.
3. User goes through the same Hosted control plane and nodepool updates in the ACM console.

Why is this important?

Currently we support upgrading imported OCP standalone clusters so we want HCP cluster support to align with this.

Scenarios

1. Customer creates a HCP cluster outside of ACM and imports to ACM to be managed by ACM
2. Customer create a ROSA HCP cluster and imports to ACM to be managed by ACM

Acceptance Criteria

...

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.