OCB's existing API is internal. The current Update API is non-existent.

Assuming that the OCB MachineOSBuilder API gets implemented in the TechPreview or GA epic for OCB, this API will serve as a sibling. (will link card here)

An internal update API is a good start. However, combining the bootc integration effort with a larger goal of creating a public facing update API would be heplful for:

1. Admin Defined Update Policies
2. Switching Update backends seamlessly (between bootc and rpm-ostree)
3. consolidating update code into one area of the MCO and making update calls easier to understand.
4. Monitoring Updates

Making this API would not only sole this epic seamlessly but would contribute to solving multiple other state and admin defined configuration epics.

The Types that feed into the CRD would look like the following

type OSUpdaterBackend string

const (
  RpmOstreeOSUpdater OSUpdaterBackend = "rpm-ostree"
  BootcOSUpdater     OSUpdaterBackend = "bootc"
)

type MachineOSUpdater struct {
  MachineOSUpdaterSpec
  MachineOSUpdaterStatus
  ObservedGeneration int
...
}

type MachineOSUpdaterSpec struct {
 DesiredConfig string
 DesiredImage string
 Backend OSUpdaterBackend
 ...
}

type MachineOSUpdaterStatus struct {
 Conditions []metav1.Condition
 
}

basically the API would provide a central place for storing and viewing Update related status and spec. A user would configure key aspects of their updater experience here. This would work in conjunction with the MachineOSBuilder public api that zzlotnik@redhat.com and I are sketching up.