Skip to content
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

Questions about naming of pulled images #1139

Closed
mtrmac opened this issue Jul 23, 2018 · 12 comments

Comments

Projects
None yet
6 participants
@mtrmac
Copy link
Collaborator

commented Jul 23, 2018

(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

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

@baude PTAL

@mtrmac

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 24, 2018

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

@baude

This comment has been minimized.

Copy link
Collaborator

commented Jul 26, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 26, 2018

(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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

@rhatdan

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

@baude

This comment has been minimized.

Copy link
Collaborator

commented Nov 20, 2018

sure, anytime

@rhatdan

This comment has been minimized.

Copy link
Member

commented Dec 22, 2018

@mtrmac @baude Whats going on with this issue?

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Jan 10, 2019

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

@mheon mheon removed this from the 1.0 milestone Jan 10, 2019

@rhatdan

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@baude What is the state of this Issue now?

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Mar 8, 2019

Per @mtrmac we have removed most if not all cases of the literal :none tag.
I think we're good to close.

@mheon mheon closed this Mar 8, 2019

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Mar 8, 2019

(Our matching logic for ImageParts is still a problem, but we can replace that at a later date)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.