container: Add support for re-exporting a fetched container #642
Conversation
Just a drive by.
The status quo today is basically that with a "pure ostree" container image, one can pull it, and one *can* re-export it with `ostree container encapsulate`...but doing so loses *all chunking* i.e. you end up with a single giant layer again. Further, we don't support exporting derived images at all. Fix both of these with a new CLI and API, for example: ``` $ ostree container image reexport --repo=/path/to/repo registry:quay.io/exampleos/someos:latest containers-storage:localhost/exampleos ``` Now...before one gets too excited, this is still suboptimal in a bunch of ways: - Copying to `containers-storage` is super inefficient, we indirect through a local `oci` directory because of the lack of "push" support in containers-image-proxy, *and* we end up with a full physical copy of the files even when we *could* reflink; cc containers/storage#1849 - Because we don't currently save tar-split data, the use case of pushing to a registry is virtually guaranteed to produce changed diffids, and we'll hence end up duplicating layers on the registry Now what is more interesting is that this code is going to help us a bit for the use case of "recommitting" a derived container image. Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
container-export
branch
from
d81e489 to
4374c05
Compare
| // Build a derived image | ||
| let srcpath = src_imgref.name.as_str(); | ||
| let temproot = &fixture.path.join("temproot"); | ||
| || -> Result<_> { |
There was a problem hiding this comment.
This looks like magic to me... the examples I see of closures assign to a variable. Is this using a closure to use the variables you just declared before instead of writing a function and passing variables to it?
There was a problem hiding this comment.
BTW, totally fine asking questions like this on PRs, please continue to do so!
This is an IIFE - it's...somewhat unusual. The rationale here is actually so that .context("generating temp content")?; applies to everything inside the closure - it's a way of adding context to a whole bunch of ? without actually splitting it out into a separate function as you say.
Splitting into a separate function is more heavyweight: requires spelling out all the types and passing all the inputs.
But yes, I don't see IIFEs in much other Rust code, and I don't tend to use them often. If I remember right, I added this one because I had a bug somewhere in all those lines and I didn't want to change everything to use unwrap().
There was a problem hiding this comment.
thanks for explaining it, I appreciate it! that makes sense to me now.
There was a problem hiding this comment.
That said, I actually copy-pasted this, so #643 dedups it
chunking: Add some doc comments
Just a drive by.
container: Add support for re-exporting a fetched container
The status quo today is basically that with a "pure ostree"
container image, one can pull it, and one can re-export
it with
ostree container encapsulate...but doing soloses all chunking i.e. you end up with a single
giant layer again.
Further, we don't support exporting derived images at all.
Fix both of these with a new CLI and API, for example:
Now...before one gets too excited, this is still suboptimal
in a bunch of ways:
containers-storageis super inefficient, we indirectthrough a local
ocidirectory because of the lack of "push"support in containers-image-proxy, and we end up with a full
physical copy of the files even when we could reflink;
cc Support for copying between security domains containers/storage#1849
case of pushing to a registry is virtually guaranteed to produce
changed diffids, and we'll hence end up duplicating layers
on the registry
Now what is more interesting is that this code is going to help
us a bit for the use case of "recommitting" a derived container
image.
Signed-off-by: Colin Walters walters@verbum.org