The biggest open question right now is, "Can rpm-ostree and bootc coexist provided that no overlapping functionality is utilized?" To better understand what this statement means, it is important to outline the capabilities of both bootc and rpm-ostree so that any intersections are known:

With this in mind, we need to answer the following questions:

• What are all of the rpm-ostree subcommands that the MCD uses? Are there bootc equivalents to them?
• Can we use bootc for switching the OS image and interrogating status like we use rpm-ostree today?
• Can we use bootc for those things while still being able to use rpm-ostree for package management and kernel argument management? Or is on-cluster layering a hard requirement for bootc adoption?
• What happens when we transition from using rpm-ostree for OS image management to using bootc, e.g., such as in an upgrade situation?
• How difficult would it be to put the bootc-specific path behind a feature gate?

What do the answer to these questions mean?

• If bootc and rpm-ostree can coexist on a system simultaneously, that means we can be more precise about adopting it.
• If bootc and rpm-ostree cannot coexist, then we need to figure out how to integrate bootc into the MCD in such a way that it can be put behind a feature gate.

How we can answer these questions:

• One could do some ad-hoc testing on a cluster node by manually bootc switching images, installing packages, and setting kernel arguments to see what happens.
• We could open a PR to the MCO repo purely for experimental purposes that uses bootc in place of rpm-ostree for applying OS images and interrogating system status. This code could later become the basis for more involved work such as putting bootc behind a feature gate, but it will be considered throwaway code for the purposes of this experiment.
• There is some preexisting code which forms the basis for a simple bootc client here: https://github.com/openshift/machine-config-operator/blob/main/pkg/daemon/bootc.go. This code is currently not being used anywhere within the MCD.
• For upgrades, we’ll need to build a release that uses the current code path along with a release that uses the bootc path. We can then use Clusterbot to run an upgrade e2e test.
• We’ll probably also want to consider the scenario of going from RHEL9 rpm-ostree -> RHEL10 bootc in our upgrade scenarios as well.
• We’ll also want to run our on-cluster layering e2es with bootc as well (maybe this is covered by MCO-1243).

Done When:

• We’ve answered the above questions and have documented those answers in the form of a writeup, additional JIRA cards, etc.