The biggest open question right now is, "What happens when we enable bootc?" 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 keep the non-layered update path active for now.
• 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 since we will need to keep the non-layered update path present while also enabling the image-mode path to exist.

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.