Can bootc operate in a more mutable fashion?

[cgwalters]

Again, proxying a question asked in a live chat:

Is there a way to change a Bootc enabled machine to a traditional dnf enabled machine?
Use case, I have an offline environment of a few CentOS machines that’s using DNF mirrors for updates. We don’t have capacity to upgrade the infrastructure to support Bootc… yet, but soon
As an interim option we’re looking to see if we can leverage the IaC & GitOps etc benefits that Bootc provides to build and deploy the machines, but change to traditional ways to maintain them. I know this can be done with a number of tools like Packer, but we’re invested in Bootc & the containers ecosystem and would rather have an interim solution before we move to full Bootc in the next 12/24 months.

[cgwalters]

This came up in a RHT internal discussion a while back. It would be possible yes...however, did you investigate setting transient root? https://containers.github.io/bootc/filesystem.html#enabling-transient-root If you don't need dnf upgrade kernel and such to persist across reboot, then I think one can get pretty far at letting usual ansible/chef style workflows to operate. One thing some people do is embed ansible playbooks (or equivalent) in their image, that run on first boot each time. This can be a useful stepping stone - move the config management you can to build time, keep the stuff that needs runtime specific config (e.g. something parsing MAC addresses or contacting an inventory server) at runtime.

[cgwalters]

That said, we could add a mode to bootc install where it just unpacks the container into the root filesystem as is - no ostree stuff, and everything would be writable at runtime etc. This would mean dnf|apt upgrade would Just Work, etc.

Only a few bits of bootc would be used here; mostly the bootloader writing parts, etc. It'd basically be the bootc install parts.

It honestly would likely be relatively straightforward to do. It's just more the longer term cost of supporting it and adding another option into our already complex matrix.

My hope is that transient root provides enough of a bridge for people who want this today instead.

[defrostediceman]

Thanks for the response Colin.

We have looked at the root/etc transients, but I don't think they meet the requirement for these use cases. The limiting factor is enabling infrastructure i.e the ability to do out of bands updates. DNF mirrors and the assurance of the packages is mature in most ops processes, whereas the equivalnent for OCI images isnt there yet. Having a feature like this will allow teams utilise the common bootc patterns for developing, building, maintaining (and so on) the OS images but with the ability to deploy them on exisiting (traditional) infrastructure.