Add `bootc commit`

[cgwalters]

Let's consider adding a flow like podman commit that creates a bootable container image state from the running host. This would be really useful in concert with a transient rw rootfs as it would allow people to explicitly persist hotfixes where desired.

Upgrade

This is out of scope.

Intersection with configmap/layers

The more I think about this the more I feel it intersects with #22

Proposed flow example with dnf

$ dnf -y install --persist bpftrace
...
Created floating layer: dnf-local
$ bootc status
Booted image: quay.io/exampleos/exampleos@sha256:...
Floating layers:
  - bootc-storage:dnf-local (pinned: true)
  - registry:quay.io/customer/ca-certificates:latest
$ reboot
... # now i have bpftrace across reboot
$ bootc upgrade
error: Pinned floating layer bootc-storage:dnf-local is not compatible with upgrades
  To remove: bootc floating-layers remove bootc-storage:dnf-local 

But it'd be nice to have a dnf option for this too: dnf -y remove --bootc-floating-layers

[jeckersb]

I think this is a fantastic idea that really drives home the big-picture model of how this is all supposed to work together.

[stefwalter]

@cgwalters We also need one place that understands whether some part of the state of the system is transient, including:

• Changes made to a transient rw rootfs
• Changes made to the kernel at runtime (eg: via kpatch)

Do you think bootc is the right tool to ask for such a flag?

[cgwalters]

I'm not sure. As far as dynamic runtime changes, for example systemd supports "drop-ins" in /run that can affect units (and there's already a systemd-delta tool etc. for introspecting that). What's trickier is there's not really any kind of rigorous way to distinguish "runtime state that is expected from code included in the image" from "runtime state changes made later by an admin interactively over ssh".

For example...beyond just kpatch, there's also something doing a modprobe on some 3rd party kernel module that may have come from curl or a container or whatever.

Or really for that matter, just...starting a process over ssh is transient state, right?

ISTM that bootc's scope at least to start should be closer to just filesystem changes in the overlay in / - anything else really broadens our scope into full-blown generic Linux systems management right?

Another way I look at this is I was seeing bootc as a "do one job and do it well" kind of tool, very much intended to be usable just as a component in a stack...so a higher level tool could start to do stuff like that.

But (arguing with myself a bit)...it would definitely make sense to me to support a whole OCI-native flow for storing kpatch objects in an OCI container, and having bootc help fetch/apply those. And if we do that then because we performed the change, we should clearly be reflecting the status.

[cgwalters]

This one will block rpm-software-management/dnf#2233