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: running containers fails when "NetworkMode" is "default" (which is the default value docker-py uses) #8544

Closed
riyad opened this issue Dec 1, 2020 · 3 comments · Fixed by #8551
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

@riyad
Copy link
Contributor

riyad commented Dec 1, 2020

/kind bug

Description

Trying to find regressions from Podman 2.1.1 by exercising the APIv2 trough docker-py's test suite (see #5386) I came across a regressions in the CreateContainerTest.test_group_id_ints test.

A container is incidentally created with "NetworkMode": "default". Trying to start it later fails with "no net configurations found in /etc/cni/net.d".

"NetworkMode" is set to "default" as a default/fallback value by docker-py and has been for at least 4 years. Although neither documented in the CLI nor in the API docs (under HostConfig->NetworkMode) "default" seems to get special treatment within the Docker engine (but I'm not sure how far it goes).

Steps to reproduce the issue:

# inside the podman repo
./bin/podman system service -t 0

In another shell

curl -sS --unix-socket /var/run/user/1000/podman/podman.sock -XPOST 'http://localhost/v1.40/containers/create' -H 'Content-Type: application/json' -d '{"Tty": false, "OpenStdin": false, "StdinOnce": false, "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["id", "-G"], "Image": "alpine:3.10", "NetworkDisabled": false, "HostConfig": {"NetworkMode": "default", "GroupAdd": ["1000", "1001"]}}'

# put the "Id" value from response in the URL
curl -sS --unix-socket /var/run/user/1000/podman/podman.sock -XPOST 'http://localhost/v1.40/containers/8d510dd4d4a9cd5a2917c58e4dbc7f177091724e1f88625af5b3cd0f75096485/start'

Describe the results you received:

The API call to start the container fails and returns this:

{
  "cause": "command rootless-cni-infra [alloc 8d510dd4d4a9cd5a2917c58e4dbc7f177091724e1f88625af5b3cd0f75096485 default reverent_greider] in container cc3fc0bd9e2c074b76212fce171a5f48966b8cc4471b0fe9aa21fe4f80ac59ee failed with status 1, stdout=\"\", stderr=\"no net configurations found in /etc/cni/net.d\\n\"",
  "message": "command rootless-cni-infra [alloc 8d510dd4d4a9cd5a2917c58e4dbc7f177091724e1f88625af5b3cd0f75096485 default reverent_greider] in container cc3fc0bd9e2c074b76212fce171a5f48966b8cc4471b0fe9aa21fe4f80ac59ee failed with status 1, stdout=\"\", stderr=\"no net configurations found in /etc/cni/net.d\\n\"",
  "response": 500
}

It creates/leaves a weird container:

$ podman ps -a
CONTAINER ID  IMAGE                                                                                                      COMMAND         CREATED             STATUS             PORTS   NAMES
cc3fc0bd9e2c  quay.io/libpod/rootless-cni-infra@sha256:304742d5d221211df4ec672807a5842ff11e3729c50bc424ea0cea858f69d7b7  sleep infinity  32 seconds ago      Up 31 seconds ago          rootless-cni-infra
8d510dd4d4a9  docker.io/library/alpine:3.10                                                                              id -G           About a minute ago  Created                    reverent_greider

Describe the results you expected:

When the container runs successfully the logs would have the output from the id command:

$ podman logs ...
0 1000 1001

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

This worked on Podman 2.1.1 and fails on 3.0-dev (currently: b2cd6e0). FWIW using "private" instead of "default" makes it work.

Grepping through the test logs the "no net configurations found in /etc/cni/net.d" error message is the (superficial?) cause of failure for 50 of the API tests ATM. 😐

Output of podman version:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.15.2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: systemd
  cgroupVersion: v2
  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: journald
  hostname: acnologia
  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-54-generic
  linkmode: dynamic
  memFree: 796901376
  memTotal: 16544563200
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/local/bin/crun
    version: |-
      crun version 0.16
      commit: 91ec195708efb8eed1699d59cd0369d639d8a7a8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.7
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 1684824064
  swapTotal: 2147479552
  uptime: 110h 40m 34.23s (Approximately 4.58 days)
registries:
  search:
  - docker.io
store:
  configFile: /home/riyad/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  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.1.0
        FUSE library version 3.9.0
        using FUSE kernel interface version 7.31
    overlay.mountopt: nodev
  graphRoot: /home/riyad/podman/storage
  graphStatus:
    Backing Filesystem: zfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 18
  runRoot: /run/user/1000
  volumePath: /home/riyad/podman/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 2.1.1

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

podman/unknown 2.2.0~0.1+nmu3 amd64 [upgradable from: 2.1.1~2]
podman/unknown 2.2.0~0.1+nmu3 arm64
podman/unknown 2.2.0~0.1+nmu3 armhf
podman/unknown 2.2.0~0.1+nmu3 s390x

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Dec 1, 2020
@riyad riyad changed the title APIv2: running containers fail when "NetworkMode" is "default" (which is the default value docker-py uses) APIv2: running containers fails when "NetworkMode" is "default" (which is the default value docker-py uses) Dec 1, 2020
@rhatdan rhatdan self-assigned this Dec 2, 2020
@rhatdan rhatdan added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Dec 2, 2020
rhatdan added a commit to rhatdan/podman that referenced this issue Dec 2, 2020
Docker defines an option of "default" which means to
use the default network.  We should support this with
the same code path as --network="".

This is important for compatibility with the Docker API.

Fixes: containers#8544

Signed-off-by: Daniel J Walsh <[email protected]>
@rhatdan
Copy link
Member

rhatdan commented Dec 3, 2020

@riyad Now that the "default" is a valid NetworkMode in the main branch, could you verify that this fixed your issue.

@yan12125
Copy link
Contributor

yan12125 commented Dec 3, 2020

Thanks for the fix! I happened to get this issue from docker-py these days, and I can confirm the issue is gone with podman 70284b1.

@riyad
Copy link
Contributor Author

riyad commented Dec 3, 2020

Awesome! Yes, it did the trick. 😃

mheon pushed a commit to mheon/libpod that referenced this issue Dec 7, 2020
Docker defines an option of "default" which means to
use the default network.  We should support this with
the same code path as --network="".

This is important for compatibility with the Docker API.

Fixes: containers#8544

Signed-off-by: Daniel J Walsh <[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 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
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.

4 participants