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

APIv2: container list limit handling seems to differ from docker-API #7722

Closed
rsommer opened this issue Sep 22, 2020 · 1 comment · Fixed by #7739
Closed

APIv2: container list limit handling seems to differ from docker-API #7722

rsommer opened this issue Sep 22, 2020 · 1 comment · Fixed by #7739
Assignees
Labels
HTTP API Bug is in RESTful API 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

@rsommer
Copy link
Contributor

rsommer commented Sep 22, 2020

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

/kind bug

Description

While trying out podman API with traefik, I came across differences in API behaviour:

Steps to reproduce the issue:

  1. podman --log-level debug system service -t 0
  2. podman run nginx
  3. curl -s --unix-socket /var/run/user/1000/podman/podman.sock "http://v1.24/containers/json?limit=0" (which is what is requested using the docker client used by traefik)
    This yields an empty array '[]', using 'limit=1', you'll get the expected container

On the other hand:

  1. Start docker daemon
  2. docker run nginx
  3. curl -s --unix-socket /var/run/docker.sock "http://v1.24/containers/json?limit=0"
    [{"Id":"fa3efdb9c1e2e5484c33ebcb03ae309c677ee3907b5e6094f87efcf333c63175","Names":["/pedantic_sanderson"],"Image":"nginx","ImageID":"sha256:7e4d58f0e5f3b60077e9a5d96b4be1b974b5a484f54f9393000a99f3b6816e3d","Command":"/docker-entrypoint.sh nginx -g 'daemon off;'","Created":1600779318,"Ports":[{"PrivatePort":80,"Type":"tcp"}],"Labels":{"maintainer":"NGINX Docker Maintainers <docker-maint@nginx.com>"},"State":"running","Status":"Up 15 seconds","HostConfig":{"NetworkMode":"default"},"NetworkSettings":{"Networks":{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"7fbf25166e9904904e9fc4937058f644cf73da9aea191ff556772d8a8a89541f","EndpointID":"e066dd7864e74d0ec7bf4348eabd79ab459287bb69333d4c5ad73ea2fda57de0","Gateway":"172.17.0.1","IPAddress":"172.17.0.2","IPPrefixLen":16,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":"02:42:ac:11:00:02","DriverOpts":null}}},"Mounts":[]}]

Describe the results you received:
podman API yields an empty array using the same API call, while docker returns a list of containers.

Describe the results you expected:
I would expect the same behaviour due to API-compatibility.

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

Output of podman version:

Version:      2.0.6
API Version:  1
Go Version:   go1.14.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.1
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.20, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: file
  hostname: aragorn
  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.4.0-47-generic
  linkmode: dynamic
  memFree: 216760320
  memTotal: 8223502336
  ociRuntime:
    name: runc
    package: 'cri-o-runc: /usr/lib/cri-o-runc/sbin/runc'
    path: /usr/lib/cri-o-runc/sbin/runc
    version: 'runc version spec: 1.0.2-dev'
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.4
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 1144066048
  swapTotal: 2147479552
  uptime: 31h 43m 36.79s (Approximately 1.29 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/codex/.config/containers/storage.conf
  containerStore:
    number: 34
    paused: 0
    running: 0
    stopped: 34
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/codex/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 48
  runRoot: /run/user/1000/containers
  volumePath: /home/codex/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.2
  OsArch: linux/amd64
  Version: 2.0.6

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

podman/unknown,now 2.0.6~2 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

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

$ docker version
Client:
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.13.8
 Git commit:        afacb8b7f0
 Built:             Tue Jun 23 22:26:12 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.8
  Git commit:       afacb8b7f0
  Built:            Thu Jun 18 08:26:54 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.3-0ubuntu2
  GitCommit:        
 runc:
  Version:          spec: 1.0.1-dev
  GitCommit:        
 docker-init:
  Version:          0.18.0
  GitCommit:        
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Sep 22, 2020
@mheon mheon added the HTTP API Bug is in RESTful API label Sep 22, 2020
@mheon
Copy link
Member

mheon commented Sep 22, 2020

@ParkerVR Mind taking this one?

@TomSweeneyRedHat TomSweeneyRedHat added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Sep 23, 2020
@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 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
HTTP API Bug is in RESTful API 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.

6 participants