Updated description as of 4.19:

The Hypershift implementation will likely 1. trail behind self-hosted OCP by a few releases, both for stability and due to the nature and additional work required for Hypershift and 2. have a separate API (and architecture) for image builds and rollouts.

API Considerations:

There's two alternatives in terms of implementing the Hypershift API

1. implement a hypershift-only variant of MachineOSConfig and MachineOSBuild. The main difference is that they will be namespaced, and likely have some different configurables
   1. Pros: a full fledged API that comes with validation
   2. Cons: slightly more involved to implement. Cannot be at the management cluster level as we would be locking the build behind support in the management cluster version/architecture, so this will likely be managed and rolled out at the hosted cluster's control plane level instead (should investigate details on this)
2. use the existing MCO API embedded into configmaps at the management cluster API level
   1. Pros: matches how MachineConfigs are done today, and doesn't require a new API, so the user can use the same API as the self-hosted OCP
   2. Cons: no validation of API and easier to make mistakes via a configmap indirection

Regardless, this will likely take more than 1 release to implement, especially with the new API route as it would need to be via a new v1alpha API behind a techpreview featuregate.

Hypershift Code Changes:

Once the API is in place, each hosted cluster would need to add ability to

1. process the new API object, like the MCController would do for self-hosted OCP
2. run builds via a build pod, likely a variant of the MCO's current build pod
3. a registry at the hosted control plane level for each cluster (practically, on the worker nodes of the management cluster) or forced external registry requirement (could be multi-phased here as well)
4. adapt the existing ignition server in Hypershift, and MCD's hypershift inplace upgrade routes to handle the new image