Turn into strict superset of bootc

[cgwalters]

It'd be good to change rpm-ostree to call out to bootc instead for container operations, instead of directly talking to ostree-ext where possible; this would give us one source of truth for container code.

We'd need a stable progress API in bootc to do this.

Also this in general implies that features added to bootc are also rpm-ostree features by default; things like logically bound images.

[jlebon]

Hmm, is this basically containers/bootc#347 but flipping what drives what? Notably, the main thing that is required regardless would be to have a way for bootc to only download and import but not deploy an update.

[cgwalters]

Hmm, is this basically containers/bootc#347 but flipping what drives what?

Seems reasonable to view it that way yeah.

Notably, the main thing that is required regardless would be to have a way for bootc to only download and import but not deploy an update.

Yes that and a stable progress API are the main things I can think of.

However, there's another important thing here actually...until package layering is ported, bootc can't do unified storage - or at least, would need to be forced into a mode where we still create an ostree commit.

[cgwalters]

xref ostreedev/ostree-rs-ext#675

[jlebon]

I think this makes sense. I closed containers/bootc#347 in favour of this one.

I think this would help FCOS, OCP, and dnf+bootc.

[jmpolom]

It'd be good to change rpm-ostree to call out to bootc instead for container operations, instead of directly talking to ostree-ext where possible; this would give us one source of truth for container code.

Isn't bootc based on ostree-ext? I see it in the Cargo.toml... Why is there more than one source of truth at all if these are effectively using the same library? That points to a deficiency in the library providing the necessary functions that can be shared across uses. This is a code re-use issue and it sounds like the price will be that users who are uninterested in bootc end up having to have it on their systems to satisfy a shell out rpm-ostree makes?

[cgwalters]

I pushed https://src.fedoraproject.org/rpms/rpm-ostree/c/e31f656abc0d451f0ffdd2a3afd60944796c2246?branch=rawhide to rawhide and am considering doing F41 as well.

[cgwalters]

Why is there more than one source of truth at all if these are effectively using the same library?

Because we've added new features to bootc that aren't part of ostree-rs-ext, such as kernel arguments, logically bound images, etc. To be clear, we will continue to where it makes sense to internally structure sub-components as reusable libraries (mostly Rust crates hopefully) or binaries. An example of that investment is in composefs, which is not specific to bootc/ostree/containers/OCI and we are aiming to make a foundational generic infrastructure piece.

This is a code re-use issue and it sounds like the price will be that users who are uninterested in bootc end up having to have it on their systems to satisfy a shell out rpm-ostree makes?

There are very definitely people using rpm-ostree today who are not using containers. I don't believe you are one of them though?

My PoV here is that rpm-ostree already indirectly includes quite a lot of things - especially the dnf stack - and we Requires: skopeo already too for containers; adding bootc to that is just another ~6M cost.

People who are interested in making actually smaller systems I think are going to be excited by bootc, not opposed because it allows dropping out the whole RPM stack for example that is just dead weight most of the time for appliance systems.

[jlebon]

I pushed src.fedoraproject.org/rpms/rpm-ostree/c/e31f656abc0d451f0ffdd2a3afd60944796c2246?branch=rawhide to rawhide and am considering doing F41 as well.

Not strongly against, but until the relationship described in this issue is established in the code, having both will just add confusion. And ideally in that setup, bootc status can say something like "Driven by rpm-ostree"? So that the relationship is clear/discoverable.

[cgwalters]

Not strongly against, but until the relationship described in this issue is established in the code, having both will just add confusion.

Can you elaborate on what confusion you see?

And ideally in that setup, bootc status can say something like "Driven by rpm-ostree"? So that the relationship is clear/discoverable.

Hmm. Is your concern that people may be doing if test -x /usr/bin/bootc and assuming that that means it's being used?

[jmpolom]

Is the intention here to as I said "shell out" to bootc from rpm-ostree or use bootc as a rust crate? I may have misunderstood the intended method of interoperating with the two because it really wasn't described in detail here.

There are very definitely people using rpm-ostree today who are not using containers. I don't believe you are one of them though?

I was for a time but have since switched to containers as it seems like that's the intended future direction for composable ostree systems? Personally I would prefer to have a way to compose derivative non-container ostree builds and compress the resulting image into a deployable flat file. The container experience isn't entirely ideal but it does allow for derivation and re-use of builds pretty easily. Does bootc intend to support a non-container approach at some point?

People who are interested in making actually smaller systems I think are going to be excited by bootc, not opposed because it allows dropping out the whole RPM stack for example that is just dead weight most of the time for appliance systems.

Do you have a working example of a base image and derivative image build that result in compatible containers with zero package management tooling inside? For example how do you remove rpm-ostree, bootc, rpm, etc. from an image you're deriving from? It is clear to me how this could be done when building from 0 with rpm-ostree but there has been talk about moving away from rpm-ostree to building base images.

[cgwalters]

Is the intention here to as I said "shell out" to bootc from rpm-ostree or use bootc as a rust crate? I

Subprocess over varlink is current thought, xref containers/bootc#522

I was for a time but have since switched to containers as it seems like that's the intended future direction for composable ostree systems? Personally I would prefer to have a way to compose derivative non-container ostree builds and compress the resulting image into a deployable flat file.

What's your goal with "deployable flat file"? Like a raw disk image you can dd? That of course exists in multiple forms, but I assume you're here though because you want to have incremental in place updates and not fetch disk images? Is your concern more something like offline/disconnected environments and being able to easily get OS images across? I think that's covered by serializing to an OCI directory or archive if that's the goal.

Do you have a working example of a base image and derivative image build that result in compatible containers with zero package management tooling inside?

So bootc is explicitly intended to enable this and it is definitely possible with some custom build work. However one thing that I needed to do and took a surprising amount of time was this MR to selinux-policy. Now that that's at least in f41 I think we can restart this better.

The short answer is no I don't have that example, but we have been working towards it and a few pieces are coming together.

[cgwalters]

#5187 and https://src.fedoraproject.org/rpms/bootc/c/50bd1d9415ab42a263ff651a2ca5cff328450bb1?branch=rawhide landed, so in Fedora rawhide right now the transition of ownership of the ostree container CLI is in progress.

[cgwalters]

The biggest thing then is to land containers/bootc#921 and change the code here to fork off bootc as a binary.