openshift / pivot

Pivots from on ostree OS/Deployment to another via containers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Pivot error: "Docker references with both a tag and digest are currently not supported"

jlebon opened this issue · comments

pivot version 0.0.1 (613316e4504010f953e1df4587152ef09c19f444)
Running: skopeo inspect docker://registry.svc.ci.openshift.org/rhcos/os-maipo:latest
error pulling image "registry.svc.ci.openshift.org/rhcos/os-maipo:latest@sha256:31220b35b7ca38d431b7e699ad848222cd14cef55fe219570086e31c78a15af5": unable to pull registry.svc.ci.openshift.org/rhcos/os-maipo:latest@sha256:31220b35b7ca38d431b7e699ad848222cd14cef55fe219570086e31c78a15af5: error getting default registries to try: unable to parse 'registry.svc.ci.openshift.org/rhcos/os-maipo:latest@sha256:31220b35b7ca38d431b7e699ad848222cd14cef55fe219570086e31c78a15af5': Docker references with both a tag and digest are currently not supported
F0911 15:59:20.056969    1308 run.go:22] podman: exit status 125

@jlebon do you happen to know what the pivot invocation looked like?

# ./pivot registry.svc.ci.openshift.org/rhcos/os-maipo:latest

Thanks @jlebon. I'll take a look.

Looks like podman no longer supports the format used in pivot here. @mrunalp is this a known change or should we be able to rely on $IMAGE:$TAG@$DIGEST?

@mrunalp noted it's actually skopeo which doesn't like the format any longer.

The goal of this code is to implement "idempotence" - if we've already pivoted to an existing container sha256, don't download it again.

Probably we could implement this by directly linking to c/image, but the direct skopeo invocation was convenient.

@mtrmac ptal as well

For reference, this is from FAH 28. It works fine from RHCOS.

F28AH:

[root@f28-tmp ~]# rpm -qa | grep -E '(skopeo|podman)'
podman-0.8.3-4.git9d09a4d.fc28.x86_64
skopeo-0.1.31-13.dev.gite3034e1.fc28.x86_64

RHCOS:

[root@localhost ~]# rpm -qa | grep -E '(skopeo|podman)'
skopeo-containers-0.1.29-3.dev.git7add6fc.el7.x86_64
podman-0.4.1-4.gitb51d327.el7.x86_64
skopeo-0.1.29-3.dev.git7add6fc.el7.x86_64

Probably we could implement this by directly linking to c/image, but the direct skopeo invocation was convenient.

Not really, this is c/image rejecting the input:

unable to parse 'registry.svc.ci.openshift.org/rhcos/os-maipo:latest@sha256:31220b35b7ca38d431b7e699ad848222cd14cef55fe219570086e31c78a15af5': Docker references with both a tag and digest are currently not supported

The underlying docker/distribution HTTP API only allows referencing an image by one of a tag or a digest. What do you actually want to happen here?

  • “The image @sha256:312…, regardless of where the tag points“?
  • “The image tagged with latest, regardless of its digest“? (I guess not)
  • “The image tagged with latest, but fail if the digest is not as expected“?

So far c/image has punted on this ambiguity, and forces the callers to make a choice and use only one of the tag and digest. It’s plausible that this format of input should be accepted, but it’s not entirely obvious what the right behavior is.

(FWIW projectatomic/docker, at the CLI and API level, throws away the tag and works only with the digest, AFAICS.)

@mtrmac good information, thank you!

@cgwalters IMO we should switch over to using whatever the user provides in terms of the pull. We can still store the data in the check file before hand and stop if we've already pivoted to that hash.

WDYT?

We kinda have to canonicalize to name@digest so that we know exactly what we're pulling wrt to the idempotency check, no?

@jlebon I think you're right. That would be safer. Basically we'd strip off the tag after we've resolved the digest, replace the tag with the digest and continue to store in the check file.

Yes, seems to me most consistent with the ”idempotence” idea / being resilient to the tag changing and parallel pulls, as well.

I included a commit for this in https://github.com/ashcrow/pivot/pull/12.