Bug 1186442
| Summary: | docker load | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Chris Evich <cevich> |
| Component: | docker | Assignee: | smahajan <smahajan> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.1 | CC: | dwalsh |
| Target Milestone: | rc | Keywords: | Extras, UserExperience |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-22 18:22:58 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1184247 | ||
| Bug Blocks: | |||
|
Description
Chris Evich
2015-01-27 16:45:04 UTC
Is this the case where docker would tell us to use docker export rather then docker save? (In reply to Daniel Walsh from comment #1) > Is this the case where docker would tell us to use docker export rather then > docker save? My understanding (could be wrong) based on --help output... Usage: docker export [OPTIONS] CONTAINER Export the contents of a filesystem as a tar archive to STDOUT ...is the export command is strictly for containers (not images/repositories). Export only saves out the filesystem contents, none of the layers or other metadata (AFAIK). However, docker 'load' and 'save' DO save parent layers and metadata (since saving by name restores the name and ID). Also, I marked this 'LOW' since save/load do work (strictly speaking), so this is really mostly just a usability / automation problem. I don't think a fix is urgently needed, just something "nice" if it worked. Though I won't pretend to know all the use-cases affected :) Chris, Follow the below logs; http://pastebin.test.redhat.com/259282 Here I did `docker save docker-test-image` first using ID (img.tar) and then using image_name (img1.tar). If you see the contents of img.tar it does not have the repositories JSON which is needed to generate the image name hence <none>:<none> When you see the contents of img1.tar if has the required JSON so it generates the image name successfully. If you think about it, it seems logical, since there can be multiple tags (names) to a single ID... saving an image with an ID and loading it back would confuse docker as which name to pick since the ID could translate to multiple names. Hope that make sense :) I can try to look at your proposal, of saving all the FQINs and see if a repositories JSON file can be generated (with all the FQINs) to enable `docker save using ID` not resulting in <none>:<none> (In reply to smahajan from comment #4) > If you see the contents of img.tar it does not have the repositories JSON > which is needed to generate the image name hence <none>:<none> > ... > Hope that make sense :) Yep, I suspected something like that. So really, if it's dropping the entire JSON it's loosing much more data than just the FQIN. > it seems logical...would confuse docker Hrrrmmmm, nope, that doesn't make sense, people get confused, not programs :D Seriously though, yes, the point is for a consistent user experience. I marked this bug as depending on bug 1184247, since the load-name conflict warnings would also be really helpful. Either way, I can imagine conflict-checking on load is non-trivial to write, and docker save does work in the strictest sense. So a fix here isn't super urgent IMHO. Thanks for taking a look.
>
> Yep, I suspected something like that. So really, if it's dropping the
> entire JSON it's loosing much more data than just the FQIN.
Actually the repositories JSON just has the image name, tag and hash.
>
Issue opened with docker. https://github.com/docker/docker/issues/10592 Shishir Could you ping docker on these pull requests to see if we have any update. Shishir any update on this? Hi Dan, https://github.com/docker/docker/issues/10592 The community guy who asked to work on this, has got occupied on some contracting project. [See last 2 comments in the above issue]. I will take this over. Shishir ok PR opened upstream. https://github.com/docker/docker/pull/14809 Shishir New PR for this one. https://github.com/docker/docker/pull/15263 Shishir Any update on this one? Upstream (docker) is just completely unresponsive on this one. Shishir Well you got some response yesterday. Closing this one, as upstream believe this is a feature not a bug. According to docker: Tags and Image IDs are two separate entities. If you save an image using image ID, you should only get imageID and not tags. docker save imageID > img.tar (This would not generate repositories JSON and only save the imageID) docker load < img.tar would create an untagged (<none>:<none>) image. For more information, please check the comments in the PR: https://github.com/docker/docker/pull/15263. |