-
Notifications
You must be signed in to change notification settings - Fork 197
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
Comments
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. |
Seems reasonable to view it that way yeah.
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. |
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. |
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 |
I pushed https://src.fedoraproject.org/rpms/rpm-ostree/c/e31f656abc0d451f0ffdd2a3afd60944796c2246?branch=rawhide to rawhide and am considering doing F41 as well. |
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.
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 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. |
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, |
Can you elaborate on what confusion you see?
Hmm. Is your concern that people may be doing |
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.
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?
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. |
Subprocess over varlink is current thought, xref containers/bootc#522
What's your goal with "deployable flat file"? Like a raw disk image you can
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. |
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>
#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 |
The biggest thing then is to land containers/bootc#921 and change the code here to fork off bootc as a binary. |
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.
The text was updated successfully, but these errors were encountered: