Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn into strict superset of bootc #4994

Open
cgwalters opened this issue Jun 15, 2024 · 13 comments
Open

Turn into strict superset of bootc #4994

cgwalters opened this issue Jun 15, 2024 · 13 comments
Labels
dependencies Pull requests that update a dependency file kind/enhancement

Comments

@cgwalters
Copy link
Member

cgwalters commented Jun 15, 2024

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.

@cgwalters cgwalters added kind/enhancement dependencies Pull requests that update a dependency file labels Jun 15, 2024
@cgwalters cgwalters changed the title Don't vendor ostree-ext, fetch containers via bootc Turn into strict superset of bootc Oct 9, 2024
@jlebon
Copy link
Member

jlebon commented Oct 17, 2024

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
Copy link
Member Author

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
Copy link
Member Author

xref ostreedev/ostree-rs-ext#675

@jlebon
Copy link
Member

jlebon commented Oct 31, 2024

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
Copy link

jmpolom commented Nov 5, 2024

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
Copy link
Member Author

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

@cgwalters
Copy link
Member Author

cgwalters commented Nov 7, 2024

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
Copy link
Member

jlebon commented Nov 7, 2024

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
Copy link
Member Author

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
Copy link

jmpolom commented Nov 8, 2024

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
Copy link
Member Author

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 added a commit to cgwalters/rpm-ostree that referenced this issue Dec 9, 2024
This will pair with a forthcoming patch for bootc.spec where
it will support taking over these symlinks.

This is part of migrating the container code to bootc, and
having rpm-ostree just call it; xref
coreos#4994

Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters
Copy link
Member Author

#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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file kind/enhancement
Projects
None yet
Development

No branches or pull requests

3 participants