Entrypoint should be an array in output of podman inspect

[divergentdave]

/kind bug

Description

There is a difference in the shape of the objects returned by podman inspect and docker inspect for containers, and this difference can cause issues for downstream tools.

Steps to reproduce the issue:

Run podman inspect $(podman create postgres:14-alpine).

Describe the results you received:

Inside the Config object, Entrypoint is a single string, "docker-entrypoint.sh.

Describe the results you expected:

When I repeat the above with Docker, Entrypoint is an array of strings, ["docker-entrypoint.sh"].

Output of podman version:

Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.16.6
Built:        Wed Dec 31 18:00:00 1969
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.1.0, commit: '
  cpus: 8
  distribution:
    codename: focal
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  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.14.0-1032-oem
  linkmode: dynamic
  logDriver: journald
  memFree: 9285615616
  memTotal: 16492830720
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version UNKNOWN
      commit: ea1fe3938eefa14eb707f1d22adff4db670645d6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    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: 2147479552
  swapTotal: 2147479552
  uptime: 25m 33.89s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/david/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.9.0
        fuse-overlayfs: version 1.5
        FUSE library version 3.9.0
        using FUSE kernel interface version 7.31
  graphRoot: /home/david/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 204
  runRoot: /run/user/1000/containers
  volumePath: /home/david/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.2
  Built: 0
  BuiltTime: Wed Dec 31 18:00:00 1969
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.4.2

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

podman/unknown,now 100:3.4.2-1 amd64 [installed]
podman/unknown 100:3.4.2-1 arm64
podman/unknown 100:3.4.2-1 armhf
podman/unknown 100:3.4.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/main/troubleshooting.md)

Yes, I built it from source, and got the same result.

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

This is on a physical machine.

[bobmcwhirter]

fwiw, this currently affects testcontainers-rs which attempts to support podman in addition to docker, but deserializing the output of inspect currently breaks hard due to expectation of an array value.

[mheon]

From what I'm seeing, our Docker-compat REST API correctly treats it as an array. Or are you invoking the Podman CLI and using that?

[bobmcwhirter]

From what I'm seeing, our Docker-compat REST API correctly treats it as an array. Or are you invoking the Podman CLI and using that?

Yah, I was attempting to use testcontainers-rs using their Cli interface which supports either Docker or Podman, in theory.

I've since moved to using the HTTP client over unix socket, and that works as expected, even through qemu-x86 running on an M1 mac, with all the SSH shenanigans.