podman save fails when specifying an image using a digest

[mprahl]

/kind bug

Description

podman save fails when specifying an image using a digest

Steps to reproduce the issue:

1. podman pull quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f

2. podman save quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f -o temp.tar

Describe the results you received:

Error: error getting Docker archive ImageReference for "temp.tar:quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f": docker-archive doesn't support digest references: temp.tar:quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f

Describe the results you expected:

The archive should be created like the Docker CLI does.

Output of podman version:

Version:            1.7.0
RemoteAPI Version:  1
Go Version:         go1.12.14
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.14
  podman version: 1.7.0
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.10-2.fc30.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.10, commit: 35d9b09d9d2791c7167091a9f25792535a380967'
  Distribution:
    distribution: fedora
    version: "30"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 65536
    - container_id: 65537
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 65536
    - container_id: 65537
      host_id: 100000
      size: 65536
  MemFree: 282464256
  MemTotal: 8058654720
  OCIRuntime:
    name: runc
    package: runc-1.0.0-102.dev.gitdc9208a.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc10
      commit: ffa084d279c26351e6e63bd2c3f28d43fa1f6e57
      spec: 1.0.1-dev
  SwapFree: 7726428160
  SwapTotal: 8384409600
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: mprahl-laptop
  kernel: 5.4.17-100.fc30.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-4.git19d199a.fc30.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.2
      commit: 19d199a6ca424fcf9516320a327cedad85cf4dfb
  uptime: 4h 33m 53.01s (Approximately 0.17 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/mprahl/.config/containers/storage.conf
  ContainerStore:
    number: 9
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.5-2.fc30.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/mprahl/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 19
  RunRoot: /run/user/1000
  VolumePath: /home/mprahl/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.7.0-3.fc30.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):

physical

[vrothberg]

Thanks for opening the issue! I changed it to a feature request as it's documented to not be supported.

@mtrmac, do you know why we're not supporting it? I didn't check the specific parts in the code yet but Docker seems to be able doing that.

[mtrmac]

If you check the archive that results from (docker save name@digest), it doesn’t contain the name@digest value at all — it’s just not possible, the format (https://github.com/moby/moby/blob/749d90e10f989802638ae542daf54257f3bf71f2/image/spec/v1.2.md ) has a RepoTags field and a repo/tag structure in the repositories file.

I suppose Podman should mimic the Docker behavior and create an unnamed image in this case, or maybe (probably not?) reject the input outright.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg do you think we should do this?

[vrothberg]

I like @mtrmac's idea to mimic what Docker does. @mtrmac what do you think?

[mtrmac]

Sure, why not. AFAICS docker-archive: (preferably via archive.NewReference) already supports unnamed archives, so this is something to do around https://github.com/containers/libpod/blob/235f367861be6b7f9ca3b4a62c240a03728a7a21/libpod/image/image.go#L1416 .

[vrothberg]

@rhatdan, something for interns?

[rhatdan]

Sure unless @sujil02 gets to it first.

[vrothberg]

:trumpet: :trumpet: :trumpet: :notes: Let the games begin!

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@sujil02 Did you ever get a chance to look at this?

[sujil02]

@sujil02 Did you ever get a chance to look at this?

Nope didn't get a chance, But I can give it a shot later in the week once v2 system prune I am working on is in.

[cdjohnson]

@sujil02 Any updates on a fix for this? This is blocking our ability to use podman with opm.

[sujil02]

@sujil02 Any updates on a fix for this? This is blocking our ability to use podman with opm.

Currently working on this only. PR will be out soon.

[sujil02]

@sujil02 Any updates on a fix for this? This is blocking our ability to use podman with opm.

@cdjohnson issue fixes with #6011

[jeyaramashok]

@sujil02 do you know which release would have this change ? and roughly when that release would be available ?

[mheon]

As things stand now, Podman v2.0.0, probably in 4-6 weeks. If this is a critical issue we can consider a backport to the v1.9.x release series.

[cdjohnson]

@mheon
Yes, this is a very critical issue for us. Please consider this for 1.9.

FYI: It looks like Podman v2 no longer has Docker CLI compatibility, so we'll likely need to use Podman v1.9 anyway.

[jeyaramashok]

yes. It would be great if you can backport this change to 1.9.x, we've been using podman heavily along with opm tool to build catalog images for openshift. we are currently are blocked by this since the tool does a save using digests. Also since 2.0.0 is major version bump, we aren't sure what other changes the version may entail.

I can help with this , if you need.

[mheon]

v2 is just under heavy development - it will return to being CLI compatible in a few weeks. We're steadily re-enabling functionality and tests at present.

@sujil02 Mind cherry-picking the fix to the v1.9 branch? I can help you if you're not sure how.

[lcarva]

In case this is blocking anyone, here's a workaround with skopeo that works for me:

$ podman pull quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f

$ skopeo copy containers-storage:quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f docker-archive:temp.tar

If you're only pulling the image so it can be saved to an archive, then a single command will do it:

$ skopeo copy docker://quay.io/olmtest/single-bundle-index@sha256:dce3d3e858ecfb7f2ddfb0e3550a867faaf39706dfb6da71cab04f909edc428f docker-archive:temp.tar

[rhatdan]

@sujil02 Can you back port #6011 to podman 1.9?

[mheon]

Already done, AFAIK

[sujil02]

@sujil02 Can you back port #6011 to podman 1.9?

yup already done.
https://github.com/containers/libpod/pull/6032

[rhatdan]

https://github.com/containers/libpod/pull/6032
Is a back port of this for podman v1.9.
The fix will show up in podman-1.9.2

[jeyaramashok]

@rhatdan just curious, when will v1.9.2 will be released ( approx) ?

[rhatdan]

No idea. It is probably best to pester @mheon. We probably could release new minor versions every couple of weeks. We only want tiny changes, since we are concentrating mainly on podman-2.0 right now. But this is going to take a long time to stabilize.

[mheon]

Early next week sounds like a reasonable target for a 1.9.2