Documentation for OSTree Native Container migration?

Project Discussion
,
1

With F41 coming up and with it the switch to OSTree Native Container, I’ve been trying to learn what the changes will mean as a current user of Kinoite and rpm-ostree. I’ve read some information on bootc as well as the dnf cli wrapper to try to understand how things should work in the new container-based model using these new tools. However, there are still some things that are confusing and I am wondering if there will be any sort of documentation planned that’s tailored to existing rpm-ostree users to educate them to the new container tools and workflow? For example, I find the following things to be slightly confusing or need clarification:

  1. bootc seems to be the new rpm-ostree command, except for when it’s not. There seems to be a direct equivalent for many commands:

    • rpm-ostree status → bootc status
    • rpm-ostree upgrade → bootc upgrade
    • rpm-ostree rollback → bootc rollback (or dnf image rollback[1]?)
    • rpm-ostree usroverlay → bootc usr-overlay
    • rpm-ostree rebase → bootc switch (or dnf image rebase)

    However, one of the most common rpm-ostree commands used for layering packages, rpm-ostree install =/= bootc install. The latter command is used for something completely different.

  2. So how is layering going to be supported? This I found confusing and conflicting information.
    a. Under the section for Relationship with rpm-ostree in the bootc documentation, it gives the impression that layering isn’t supported fully:

    Today both bootc and rpm-ostree use the ostree project as a backing model. Hence, when using a container source, rpm-ostree upgrade and bootc upgrade are effectively equivalent; you can use either command.
    However with rpm-ostree (or, perhaps re-framed as “dnf image”), it will continue to work to e.g. dnf install (i.e. rpm-ostree install) on the client side system. In addition there are other client-side mutation commands such as rpm-ostree initramfs --enable.
    However, as soon as you mutate the system in this way, bootc upgrade will error out as it will not understand how to upgrade the system. The bootc project currently takes a relatively hard stance that system state should come from a container image

    b. Layering will still exist, but it’s unclear how to do it going forward. I don’t think we will be forced to create custom containers via Containerfiles, but its unclear whether we are supposed to use dnf install, rpm-ostree install, and whether that will break container upgrades (as stated above).

    c. Or perhaps I’m completely misunderstanding the purpose of bootc, and should stick to dnf image to manage my local machine?

  3. I think this all boils down to documenting when a user should be using bootc, dnf image, or rpm-ostree[2] commands where previously users were using just rpm-ostree.

  4. Will the switch be automatic or voluntary? On one hand, it sounds voluntary:

    If you’re a user of ostree today: no need to worry. Everything that works today in ostree and rpm-ostree will continue to work for years to come (it’s shipped in RHEL9). However, it’s expected that most users will find the new model sufficiently compelling to switch fairly quickly.[3]

    But lower in the same page it sounds like there will be an automated switchover, or maybe this systemd unit will be disabled by default:

    We will ship a systemd unit that transitions systems currently using OSTree on the wire over to tracking the corresponding container images. Note again, all features of rpm-ostree continue to work! For example, if you have layered packages, that will continue to be applied.[4]

  1. To complete this story on the client side, what is today called “ostree native containers” will be exposed via a new dnf image subcommand on the client system.
    For example:
    $ dnf image rebase quay.io/examplecorp/customos:latest
    As well as other offline/“image based” functionality such as dnf image rollback and dnf image apply-live.     ↩︎

  2. Assuming that this command will still be included and relevant, as it seems that some commands such as rpm-ostree override replace won’t be supported in the dnf wrapper ↩︎

  3. https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable#Backwards_compatibility ↩︎

  4. https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable#Upgrade/compatibility_impact ↩︎

3 Likes
2

I wonder if this systemd service isnt too early. Arent OCI containers still using more bandwidth than OSTree?

But on the other hand, F40 will be supported for a long time, until then zstd chunked containers (and more fine grainted chunkin??) can be fixed.

3

Since you haven’t made any references to the Fedora/CentOS bootc Documentation, I’m guessing you may not know it exists.

Although it may not answer all of your questions, I suggest you take a look if you haven’t already.

4

After some more searching, it seems that perhaps the F41 Changeset hasn’t been updated to reflect the latest status. It appears that the OSTree Native Container change has been withdrawn from F41, with some more work needed in bootc.

Following the discussion on dnf5 and bootc local package installation, it seems that the end goal is to replace all of rpm-ostree functionality including overlays by a combination of those 2 tools, though the mechanism hasn’t been decided or implemented yet.

@hricky, thanks for that link, I hadn’t seen it yet. Though it seems that the overlap/differences of bootc and rpm-ostree described there mirror what I read on the other site; namely:

local state mutations such as package layering, removals, or enabling e.g. rpm-ostree initramfs --enable will cause bootc upgrade to error out.
Hence if you choose to use such features, then you will need to switch over to interacting with rpm-ostree going forward for updates.

As for F41, it seems that it will stay the same as F40 for now. At least in the beta, Silverblue installation does not utilize a container image. bootc is not installed in the default installation, though it seemingly works properly if one manually rebases to a container image and overlay the bootc package. The dnf cliwrapper is not available by default, but can be enabled by running rpm-ostree deploy --ex-cliwrap=true.

With this change not imminent and still in-progress, this thread should probably be moved out of Project Discussion; I assume a migration guide/explainer will be created when this change is planned to be implemented.

1 Like
5

Short answer: There is no automatic migration happening in Fedora 41.

Long answer: It’s going to take some time to get there. There will be two things for a while: the classic ostree installations and the bootable container ones.

Each (rpm-)ostree based project has a roadmap for convergence to bootable containers:

The changes that are planned for F41 are tracked in Roadmap for Fedora 41 (#11) · Issues · fedora / bootc / Issue Tracker · GitLab

2 Likes