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

support tag@digest notation #579

Merged
merged 1 commit into from
May 26, 2021
Merged

Conversation

vrothberg
Copy link
Member

@vrothberg vrothberg commented May 26, 2021

For the sake of Docker compatibility, support the tag@digest notation.
In that case, the tag is stripped off the reference and the digest is
the sole source of truth.

Add a number of tests to make sure we're behaving as expected.

Context: containers/podman/issues/6721
Signed-off-by: Valentin Rothberg rothberg@redhat.com

@rhatdan @nalind PTAL

@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 26, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rhatdan
Copy link
Member

rhatdan commented May 26, 2021

Nice other then gofmt error.

LGTM - Makes us bug for bug compatible.

@mtrmac @containers/podman-maintainers PTAL

Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Feel completely free to ignore the unrelated comments, they don’t matter for function, and I can return to handle them correctly if there is time, later. They are basically reminders to myself.)

libimage/normalize.go Show resolved Hide resolved
libimage/normalize.go Outdated Show resolved Hide resolved
libimage/normalize.go Show resolved Hide resolved
libimage/normalize.go Outdated Show resolved Hide resolved
libimage/pull.go Outdated
// (e.g., fedora:latest@sha256...). In that case, the tag is stripped
// off and entirely ignored. The digest is the sole source of truth.
name = normalizeTaggedDigestedString(name)

Copy link
Collaborator

@mtrmac mtrmac May 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This location doesn’t make sense to me: the code should first decide what the syntax means (alltransports.ParseImageName + the other heuristics, then transform the input (and fail on errors instead of silently doing something unexpected).

That’s a bit awkward with the current dockerRef variable, but that’s because that dockerRef variable really shouldn’t exist when (looking at the strings.TrimPrefix(name, "docker://")and copyFromRegistry the code really wants to maintain a possiblyUnqualifiedDockerlikeName and not a types.ImageReference for that kind of syntax (and BTW doing that would show more explicitly that copyFromRegistry’s options.AllTags case interprets short names differently from the rest, it defaults to docker.io).


I am wondering a bit whether this shouldn’t happen in c/image/pkg/shortnames.Resolve. OTOH doing it here is consistent with the NormalizeName callers (which don’t want search), and Resolve is currently explicitly documented to preserve tags/digests, so there’s a good case for the code to live here.

libimage/runtime.go Outdated Show resolved Hide resolved
libimage/pull.go Outdated
// (e.g., fedora:latest@sha256...). In that case, the tag is stripped
// off and entirely ignored. The digest is the sole source of truth.
name = normalizeTaggedDigestedString(name)

ref, err := alltransports.ParseImageName(name)
if err != nil {
// If the image clearly refers to a local one, we can look it up directly.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

… I might be missing something; how do short names like busybox vs explicit docker://docker.io/busybox pulls work? AFAICS this code parses both into a docker://busybox ImageReference, losing the distinction — and then may try to do short name lookup on explicit docker://… formats, which should, I think, never happen — short name lookup is used only for Docker-like non-transport-qualified formats, so that the c/image-transport-qualified strings always mean the same thing in all callers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right. I agree that docker:// shouldn't do all the short-name limbo. Will fix it in another PR.

@vrothberg
Copy link
Member Author

(Feel completely free to ignore the unrelated comments, they don’t matter for function, and I can return to handle them correctly if there is time, later. They are basically reminders to myself.)

Thanks for checking. I think you're right. It's wise to make it more explicit.

@vrothberg
Copy link
Member Author

Addressed @mtrmac's comments ✔️

Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM apart from that one nit.

Thanks!

libimage/normalize.go Outdated Show resolved Hide resolved
For the sake of Docker compatibility, support the tag@digest notation.
In that case, the tag is stripped off the reference and the digest is
the sole source of truth.

Add a number of tests to make sure we're behaving as expected.

Context: containers/podman/issues/6721
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants