WIP: Use podman pull to fetch containers
#215
Conversation
|
Demo: Now, we can also expose every single And also for example, we can optimize pushes and pulls between the bootc storage and the default |
cgwalters
force-pushed
the
podman-pull
branch
5 times, most recently
from
91856eb
to
0415f12
Compare
lib/src/ostree_authfile.rs
Outdated
| @@ -0,0 +1,72 @@ | |||
| //! # Copy of the ostree authfile bits as they're not public | |||
There was a problem hiding this comment.
Let's do ostreedev/ostree-rs-ext#636
|
Ok, I've pushed my rebased and seemingly-working fork onto the original here so I can continue to iterate here instead of off in my own world. I know there are things that are still half-done or hacked-around that needs cleaned up, but this is at least something people can look at and build and play around with. |
| ostree_container::store::query_image_commit(repo, &self.ostree_commit) | ||
| .map(|v| Some(v.manifest)) | ||
| } | ||
| // TODO: Figure out if we can get the OCI manifest from podman |
There was a problem hiding this comment.
I don't think it is possible to fetch a manifest with a podman command; you'd need to fall back to skopeo inspect or something else
There was a problem hiding this comment.
We can continue to use https://github.com/containers/containers-image-proxy-rs/ for this stuff, see this API which is what's used by the ostree-container code today.
We can consider extending the proxy API too with other things we need, as it's a reliable and tested bridge between the Rust and Go sides.
There was a problem hiding this comment.
Actually also, we could fork skopeo copy and not podman pull too. That may help keep things clearer even in the short term.
| } | ||
| // Now recurse | ||
| merge_layer(layer, pathbuf, output, state)?; | ||
| } else if (src_meta.mode() & libc::S_IFMT) == libc::S_IFCHR && src_meta.rdev() == 0 { |
There was a problem hiding this comment.
are opaque directories handled (or should they)?
There was a problem hiding this comment.
I think you're right, we need to do that. Huh. So I did this search for Go code referencing trusted.overlay.opaque, it's pretty interesting all the stuff out there...including this windows tar2ext4 code. There's some interesting hits on the Rust side too, like nydus.
| //! which means the ostree deduplication is pointless. In theory this is fixable by going back | ||
| //! and changing the containers-storage files, but... | ||
| //! | ||
| //! ## Medium term: Unify containers-storage and ostree with composefs |
There was a problem hiding this comment.
One thought here...we could bite the bullet and add Go code to this project, and vendor c/storage and c/image. It'd give us the ability to even handle patches for those if need be that we release before waiting for podman or skopeo.
It would also help clear the way for us to do things like copy the podman code for quadlet files to do stuff like containers/podman#22785 right away, again without depending on podman changes in the short term.
Notable tradeoffs either way. But, the more I think about it the more I lean that direction. Does anyone have strong feelings about this?
There was a problem hiding this comment.
I'd rather stick with the tools. The tools are always released in sync to make sure that no change to c/storage, for instance, causes any unexpected regression. OCP ran into issues because of using different versions of c/storage in CRI-O and Podman.
| @@ -138,41 +153,62 @@ pub(crate) fn create_imagestatus( | |||
|
|
|||
| /// Given an OSTree deployment, parse out metadata into our spec. | |||
| #[context("Reading deployment metadata")] | |||
| fn boot_entry_from_deployment( | |||
| async fn boot_entry_from_deployment( | |||
There was a problem hiding this comment.
This whole function should probably be reworked, it's really hard to follow.
| ImageState::from(*ostree_container::store::query_image_commit(repo, &csum)?) | ||
| } | ||
| }; | ||
| //let cached = imgstate.cached_update.map(|cached| { |
There was a problem hiding this comment.
I ignored this while moving things around, needs to be addressed properly.
| .map(|d| boot_entry_from_deployment(sysroot, d)) | ||
| .transpose() | ||
| .context("Rollback deployment")?; | ||
| let staged = if let Some(d) = deployments.staged.as_ref() { |
There was a problem hiding this comment.
I don't love how this changed, but I couldn't figure out a better way to do it since await snuck in here and it doesn't play as well with the chaining+closures.
| @@ -439,7 +454,7 @@ async fn upgrade(opts: UpgradeOpts) -> Result<()> { | |||
| } | |||
| } | |||
| } else { | |||
| let fetched = crate::deploy::pull(sysroot, imgref, opts.quiet).await?; | |||
| let fetched = crate::deploy::pull(sysroot, spec.backend, imgref, opts.quiet).await?; | |||
There was a problem hiding this comment.
In the branch above here where we handle --check, it doesn't know how to store cached updates properly for the podman backend. This in turn means we don't have a good way to represent that in bootc status (it will always just be None currently)
There was a problem hiding this comment.
We have a lot of choice for how to represent this; it strongly relates to the question of image GC though. I think today, podman and c/storage generally handle this by creating containers which hold references to images.
There was a problem hiding this comment.
This also feels like more reason re: your previous comment to switch to using skopeo instead of podman, since we could use skopeo inspect to only fetch the metadata in the --check case. If I'm following correctly from the way ostree does it today it's similar in that it's just saving the manifest/config.
|
Nevermind this was just me being temporarily dumb. Of course if I switch to the latest fedora image and then boot into it, the |
We'll use this even in cases where we don't have the `install` feature. Signed-off-by: Colin Walters <walters@verbum.org>
See containers#147 (comment) With this bootc starts to really gain support for a different backend than ostree. Here we basically just fork off `podman pull` to fetch container images into an *alternative root* in `/ostree/container-storage`, (Because otherwise basic things like `podman image prune` would delete the OS image) This is quite distinct from our use of `skopeo` in the ostree-ext project because suddenly now we gain support for things implemented in the containers/storage library like `zstd:chunked` and OCI crypt. *However*...today we still need to generate a final flattened filesystem tree (and an ostree commit) in order to maintain compatibilty with stuff in rpm-ostree. (A corrollary to this is we're not booting into a `podman mount` overlayfs stack) Related to this, we also need to handle SELinux labeling. Hence, we implement "layer squashing", and then do some final "postprocessing" on the resulting image matching the same logic that's done in ostree-ext such as `etc -> usr/etc` and handling `/var`. Note this also really wants ostreedev/ostree#3106 to avoid duplicating disk space. Signed-off-by: Colin Walters <walters@verbum.org>
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
Signed-off-by: John Eckersberg <jeckersb@redhat.com>
|
Trying to catch up: Which items are open in this PR? |
Colin and I discussed this a bit last week before the holiday, the first thing I want to land is a prep change that adds the machinery for multiple backends, which initially will have just one implemented backend (the current "OstreeContainer" backend). This will force the backend API to get fleshed out, as well as help decouple the backend bits from everything else so I can (hopefully) spend less time rebasing this as things change around it. I'm going to draft a proposed backend API in a new PR that I will link here, and we can debate the design over there. Once that's in, we finish cleaning up the ideas here into the second backend implementation. This PR as-is implements the backend via There's also the opaque directory issue noted above, which I haven't given any thought to. I think that covers the known outstanding issues? |
Prep in https://github.com/containers/bootc/pull/214Move pull code into deploy
WIP: Use
podman pullto fetch containersSee #147 (comment)
With this bootc starts to really gain support for a different backend
than ostree. Here we basically just fork off
podman pulltofetch container images into an alternative root in
/ostree/container-storage,(Because otherwise basic things like
podman image prunewoulddelete the OS image)
This is quite distinct from our use of
skopeoin the ostree-ext projectbecause suddenly now we gain support for things
implemented in the containers/storage library like
zstd:chunkedandOCI crypt.
However...today we still need to generate a final flattened
filesystem tree (and an ostree commit) in order to maintain
compatibilty with stuff in rpm-ostree. (A corrollary to this is
we're not booting into a
podman mountoverlayfs stack)Related to this, we also need to handle SELinux labeling.
Hence, we implement "layer squashing", and then do some final
"postprocessing" on the resulting image matching the same logic
that's done in ostree-ext such as
etc -> usr/etcand handling/var.Note this also really wants
ostreedev/ostree#3106
to avoid duplicating disk space.