-
Notifications
You must be signed in to change notification settings - Fork 379
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
RFE: Save multiple manifests to a single file #610
Comments
@mtrmac PTAL |
Yeah, as mentioned before, c/image does not have a concept of “a pending set of images”. I’m not convinced it’s reasonable to make this a generic c/image concept, notably because the way how to designate images in that set, and the semantics of naming within the set, would be pretty tricky. But specifically for wip := archive.NewArchiveWriter(destPath)
for /* sourceRef, destinationTag */ {
destRef := wip.NewReference(destinationTag)
copy.Image(…, sourceRef, destinationRef, …)
}
wip.Finish() + adapting the existing |
@mtrmac Without even doing that, we could also have a Archive writer append to a file, no? That way, podman can just make consecutive image.Save() on the same destination and they will all end up in the same file. |
(note: this is me speaking with near zero understanding of how c/image works, so please excuse my inexperience :) ) |
Not really, the archive must contain a single Sure, each update could also append an updated version of that |
@mtrmac ah yeah okay. Are you able to implement the above solution on c/image side? I can handle adding it to podman, if so. We had another user ask on IRC today, which sets the request count to three. We can start with just the |
@haircommander @mtrmac What is the latest on this? |
@mtrmac we need input on this. |
*shrug* the technical design is clear enough, but I don’t really want to commit to a feature and a timeline to deliver it in a GitHub comment independently from the kanban board. |
@mtrmac I'll add the card and we can discuss timeline there :) |
this bit me today, and i've been trying to champion podman over docker, because of my faith in @rhatdan. |
@haircommander any update on this? |
Ping |
as reported here containers/podman#2669 (comment) |
I am trying to champion podman over docker; however, colleagues use "docker save" to air gap images to a docker-archive tarball. This translates into "podman" not being a drop-in replacement "docker", which is suboptimal. At the least, "podman save" should error out indicating "can't do multiple images" rather than silently succeeding with something that is simply not equivalent to "docker save". |
@baude @vrothberg This needs to be a top priority once APIV2 is complete. |
I believe there's already a card for it. After v2, I need to get back to systemd and auto updates first. |
@rhatdan: what's the timeline for APIV2? |
Within the next month. If someone wanted to contribute a PR to this effort, that would certainly speed up the process. |
@rhatdan: wish we were in a position to make such a PR contribution. Short of that maybe next time I'm in your neck of the woods (which I believe is 2-3 miles down the road from some of my colleagues' office in W***ford), I'll be happy to buy you a beer at the BBC. |
Sure if we ever get out of lockdown. |
Add a `MultiImageArchive{Reader,Writer}` to `docker/archive` to support docker archives with more than one image. To allow the new archive reader/writer to be used for copying images, add an `Image{Destination,Source}` to `copy.Options`. When set, the destination/source referenced will be ignored and the specified `Image{Destination,Source}` will be used instead. Fixes: containers#610 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
#996 implements this. |
There have been some requests for podman to match docker functionality in a podman save:
containers/podman#2822
containers/podman#2669
A blocker on this is the fact we can't save multiple images to the same file with containers/image. There could be a hacky work around saving them to a temp file, then appending all the files at the end, but I'd rather this happen natively in c/image.
The text was updated successfully, but these errors were encountered: