Questions about naming of pulled images

[mtrmac]

(From #1112.)

AFAICT the outcome of #1085, apart from pulling the right image, which is clearly correct, is that pulled name@sha256:digest images are named in the storage as name:none (where none is an actual tag string, not “missing”, and the digest not recorded). (I can now confidently refactor the code to do this inside the imageParts abstraction without breaking anything, but that exposes how irregular the code doing this is.)

• Is using the explicit none tag Is that intentional? If so, why is it necessary?
• Is dropping the digest and not recording it in the storage intentional? If so, why is it necessary? (Looking at Image.RepoDigests, it forms a series of name@digest values, all with the same Image.image.Digest value — but a single image (single image ID == config digest) can exist with multiple different manifest digests. Shouldn’t the original values be recorded when pulling, and reproduced in RepoDigests in podman inspect?)

Everyone has been deferring this to @baude .

[rhatdan]

@baude PTAL

[mtrmac]

Also maybe @nalind for the questions about recording original pulled digests in c/storage.

[baude]

The none tag being used is more or less what docker shows. Realistically, I think the tag is supposed to be blank. In docker, iirc, if the tag is blank, then it renders in output. I can relook at this upon return from PTO if you like ... the none for now however is on purpose.

The second point you raise looks like a bug. Can you paste an example of whats missing/what should be there and I will look to fix it.

[mtrmac]

(Enjoy your PTO; this can absolutely wait.)

The none tag being used is more or less what docker shows.

Where?

Realistically, I think the tag is supposed to be blank. In docker, iirc, if the tag is blank, then it renders in output. I can relook at this upon return from PTO if you like ... the none for now however is on purpose.

I suspect that this is strongly related to the second point actually - e.g. Docker, when pulling an image, always records a digest reference (whether pulling by tag, digest, or “all tags”), but records a tagged reference only if a tag is known (pulling by tag, or “all tags”). It’s not that a tag is “blank” when pulling by digest (which would still be different from having a none string indistinguishable from an actual :none tag), it’s that there is no tagged version of the name recorded at all.

The second point you raise looks like a bug. Can you paste an example of whats missing/what should be there and I will look to fix it.

• E.g. see the “@digest” cases in TestRefNamesFromPossiblyUnqualifiedName, the digest the user used to pull the image is not recorded by libpod at all; and it is not recorded by storage.Image either AFAICS, because storage.Digest (and storage.Image.BigDataDigests[storage.ImageDigestBigDataKey]) can only store one value. (@nalind am I missing anything?) That is a problem because…
• … a single image (single config digest) can be pulled many times from many places, with many different manifest digests (e.g. depending on how the compressed version of the layers changes as the compression implementation changes). Docker records every single name@digest reference which was actually used, and shows them all in docker inspect’s RepoDigests. As described above, Image.RepoDigests tries to compose similar results without actually having the name@digest pairs (and may thus return name@digest references which never existed at the registries).

[vrothberg]

@baude @mtrmac @nalind, ping.

[rhatdan]

@baude @mtrmac @nalind Lets revit this, Is this worth having a bluejeans session to discuss?

[baude]

sure, anytime

[rhatdan]

@mtrmac @baude Whats going on with this issue?

[mheon]

This isn't getting into 1.0 - too many changes for that release.