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

docker compatibility --platform doesn't work #10977

Closed
fugkco opened this issue Jul 18, 2021 · 4 comments · Fixed by #10979
Closed

docker compatibility --platform doesn't work #10977

fugkco opened this issue Jul 18, 2021 · 4 comments · Fixed by #10979
Assignees
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@fugkco
Copy link

fugkco commented Jul 18, 2021

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

/kind bug

Description

Seems using the --platform tag via docker doesn't pull the expected image.

Steps to reproduce the issue:

  1. Use podman to pull an arm64 image, and notice that it works fine:

    $ podman pull --platform linux/arm64 docker.io/node:12-buster-slim
    ...
    $ podman inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
    arm64
    $ docker inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
    arm64
    $ podman rmi node:12-buster-slim
    
  2. Compare with to pulling with docker, which pulls the amd64:

    $ docker pull --platform linux/arm64 docker.io/node:12-buster-slim
    ...
    $ podman inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
    amd64
    $ docker inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
    amd64
    

Describe the results you received:
Pulled image is amd64

Describe the results you expected:
Expect docker pull to pull the platform requested, in above case arm64.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:      3.2.2
API Version:  3.2.2
Go Version:   go1.14.7
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.21.0
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 8
  distribution:
    distribution: pop
    version: "21.04"
  eventLogger: journald
  hostname: pop-os
  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.11.0-7620-generic
  linkmode: dynamic
  memFree: 585052160
  memTotal: 16491663360
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1.5-925d-dirty
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      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: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 123064320
  swapTotal: 4294434816
  uptime: 233h 25m 3.35s (Approximately 9.71 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/fugkco/.config/containers/storage.conf
  containerStore:
    number: 9
    paused: 0
    running: 8
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.10.2
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.2
        using FUSE kernel interface version 7.31
  graphRoot: /home/fugkco/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 27
  runRoot: /run/user/1000/containers
  volumePath: /home/fugkco/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.2
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.7
  OsArch: linux/amd64
  Version: 3.2.2


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

$ apt list podman
Listing... Done
podman/unknown,now 100:3.2.2-1 amd64 [installed]
podman/unknown 100:3.2.2-1 arm64
podman/unknown 100:3.2.2-1 armhf
podman/unknown 100:3.2.2-1 s390x

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)

Not checked with the latest version (not in a position to upgrade right now sadly), but had a look through the changelog and nothing springs out that would have addressed this.

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

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Jul 18, 2021
@vrothberg
Copy link
Member

Thanks for reaching out, @fugkco.

$ podman pull --platform linux/arm64 docker.io/node:12-buster-slim
...
$ podman inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
arm64

This looks correct to me.

Expect docker pull to pull the platform requested, in above case arm64.

Are you mixing docker and podman? It may be a lack of morning coffee but I do not understand the problem yet. Can you elaborate a bit more?

As far as I can see, Podman behaves correctly and pulls the arm64 image. I tested Docker 20.10.6 which is also pulling down the correct.

$ docker pull --platform linux/arm64 docker.io/node:12-buster-slim
...
$ podman inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
amd64
$ docker inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
amd64

You're using docker pull but podman inspect. Maybe that's the source of confusion?

@fugkco
Copy link
Author

fugkco commented Jul 19, 2021

Hi @vrothberg,

Thanks for your time!

The issue is that when I point docker-client to podman.socket, and do a docker pull, podman doesn't pull the platform requested by docker client (it looks like it's ignoring it completely). When doing the same with podman directly, it works fine.

$ env | grep DOCKER_HOST
DOCKER_HOST=unix:///run/user/1000/podman/podman.sock
$ docker pull --platform linux/arm64 docker.io/node:12-buster-slim
...
$ docker inspect docker.io/library/node:12-buster-slim --format '{{.Architecture}}'
amd64

Here I am using docker client pointed to podman to pull the arm64 image of node:12-buster-slim, but when inspecting the image (whether via podman or docker), it is evident that podman pulled the amd64 despite the --platform arg explicitly asking for linux/arm64. On the other hand, using podman pull behaves correctly.

I put in the podman inspect commands in there for confirmation that the docker inspect command is indeed seeing the right architecture.

@vrothberg
Copy link
Member

@fugkco, thanks for clarifying. I will have a look and provide a fix.

@vrothberg vrothberg self-assigned this Jul 19, 2021
@vrothberg vrothberg added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Jul 19, 2021
@vrothberg
Copy link
Member

Opened #10979

vrothberg added a commit to vrothberg/libpod that referenced this issue Jul 20, 2021
Handle the platform parameter correctly.  The parameter was only parsed
in presence of credentials and the code was a bit complex.  Also add a
regression test.

Fixes: containers#10977
Signed-off-by: Valentin Rothberg <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants