1. Cluster administrator-initiated Upgrades: Customers upgrade HCP independent of data plane and also upgrade machine pools independent of each other. This way, customers can keep their workloads running especially when the workload can not be interrupted. Today, OCM provides API for upgrading HCP and machine pool independently along with validations for version skewing etc.
2. Service provider initiated Upgrades: Service SREs upgrade the HCP in situations such as a version is impacted by CVE or the minor version has EOL'ed. This happens without cluster administrators initiating upgrades and without impacting* the data plane

We need an UX to cover both use cases:

1. A way for both cluster administrator and service provider to upgrade HCP independent of control plane and upgrade node pools managed by Karpenter.
2. A way for SREs to upgrade HCP independent of data plane.

The rest of this is implementation detail:

We will need to create a token for each EC2NodeClass that exists in the guest cluster which is covered in this story: https://issues.redhat.com/browse/AUTOSCALE-492

However, we need a way to allow the user to initiate the upgrade, as per the first user story.

1. One option is that we can expose a new OpenshiftEC2NodeClass specific field to the user (release.Image as a similar UX to hyperv1.NodePool.spec). The changes made in AUTOSCALE-492 would then be able to react to a version change, and rollout new nodes per NodeClass.
2. Alternatively, we could allow data plane upgrades from the management cluster. For example, some interface in the management cluster (maybe we can re-use the HCP management cluster proposed CRD here?). Then OCM can provide a user interface to these fields, for the customer.

The second user story will be satisfied trivially by fulfillment of the first.

This card depends on AUTOSCALE-492, so we should design AUTOSCALE-492 with these user stories in mind.