podman-remote push doesn't report progress like local podman does #11554

petermorrowdev · 2021-09-13T19:10:29Z

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

When I run...

podman push local-image:0.1.0

Podman doesn't provide any feedback in the console about the progress of the push, like docker push does. Here's an example of what docker push outputs:

5f70bf18a086: Layer already exists
8bf241318f53: Pushed
d52afa62be4e: Layer already exists
81ef556fc488: Layer already exists
7a96378a28ad: Layer already exists
6958c02f8269: Layer already exists
b0d9eeecffb2: Layer already exists
465b8dc34802: Layer already exists
21bdddc89f96: Layer already exists
27648fb13b80: Layer already exists
1319ff37d4a9: Layer already exists
0.1.0: digest: sha256:08e70958f0ec7972f8560fbacae1i69144c26e91d69352a8n107d70d8a2e9e51 size: 2632

It also will show the size and progress of each layer as it's pushing. This feedback is something many docker users are familiar with and gives the user assurance that podman is doing what it's supposed to.

Steps to reproduce the issue:

Run podman push $IMAGE_TAG on any image you have locally.
Confirm that the console does not provide progress feedback.

Describe the results you received:

No results.

Describe the results you expected:

Described above.

Output of podman version:

Client:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.17
Built:        Mon Aug 30 12:15:26 2021
OS/Arch:      darwin/amd64

Server:
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Mon Aug 30 13:46:36 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 1
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: localhost
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.13.13-200.fc34.x86_64
  linkmode: dynamic
  memFree: 1276092416
  memTotal: 2061852672
  ociRuntime:
    name: crun
    package: crun-1.0-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.0
      commit: 139dc6971e2f1d931af520188763e984d6cdfbf8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc34.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 25h 36m 24.84s (Approximately 1.04 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 47
  runRoot: /run/user/1000/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 1630356396
  BuiltTime: Mon Aug 30 20:46:36 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.1

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

I'm pushing images from MacOS, so I ran brew desc podman here...

podman: Tool for managing OCI containers and pods

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

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

I asked about this in the #crio Kubernetes Slack Channel and was told to report an issue here, so here I am.

Thanks! 🤗

The text was updated successfully, but these errors were encountered:

afbjorklund · 2021-09-13T19:26:38Z

I'm pushing images from MacOS

I think that is your problem, it is yet another shortcoming of podman-remote

When pushing (and pulling) images with podman on Linux, there is progress...

Getting image source signatures
Copying blob 6cb051b7bcc1 skipped: already exists  
Copying blob d00da3cd7763 skipped: already exists  
Copying blob 4e61e63529c2 skipped: already exists  
Copying blob 45b0de752fd9 skipped: already exists  
Copying blob 78744c48c9d3 skipped: already exists  
Copying blob d1d5915c84e4 skipped: already exists  
Copying blob 799760671c38 done  
Copying blob 8555e663f65b done  
Copying blob 7cf0f434f498 [====================>-----------------] 288.0MiB / 512.7MiB

Maybe try running podman over ssh instead ? (podman machine ssh podman)

afbjorklund · 2021-09-13T19:35:51Z

Side note: info would be more useful, if this also included the "variant" ?

  distribution:
    distribution: fedora
    variant: coreos
    version: "34"

systemd's /etc/os-release:

NAME=Fedora
VERSION="34.20210904.1.0 (CoreOS)"
ID=fedora
VERSION_ID=34
VERSION_CODENAME=""
PLATFORM_ID="platform:f34"
PRETTY_NAME="Fedora CoreOS 34.20210904.1.0"
...
VARIANT="CoreOS"
VARIANT_ID=coreos
...

Not sure why it is being called distribution.distribution, instead of distribution.name ?

I fully understand why it is called "distribution" and not "operating system", though...

[core@localhost ~]$ sudo docker info | grep Operating
 Operating System: Fedora CoreOS 34.20210904.1.0

mheon · 2021-09-13T19:37:55Z

@jwhonce PTAL, I think we need to add progress support to the push endpoints for APIv2.

petermorrowdev · 2021-09-13T19:54:26Z

Maybe try running podman over ssh instead ? (podman machine ssh podman)

That works, but I'm pushing to a private registry (gcr.io), so I'd need to set up authentication to GCP on that machine. I'll just tough it out without the progress. It would be nice to have on MacOS though. Thanks!

vrothberg · 2021-09-27T12:51:17Z

Note that this may require some massaging in containers/image. The progress bars are only using stdout if it's TTY (see https://github.com/containers/image/blob/main/copy/copy.go#L223-L226). Probably need to hijack the connection in the server (opt-in)?

@jwhonce WDYT?

jwhonce · 2021-09-28T16:55:42Z

@vrothberg If we pull the TTY test into the caller code then it can decide whether and how to present to the "user". I would suggest a cancelable channel to pass back the progress.

github-actions · 2021-10-29T00:03:56Z