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.