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

podman doesn't add CNI interface specified via --network to container #2795

Closed
mccv1r0 opened this issue Mar 28, 2019 · 0 comments
Closed

podman doesn't add CNI interface specified via --network to container #2795

mccv1r0 opened this issue Mar 28, 2019 · 0 comments
Labels
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

@mccv1r0
Copy link
Collaborator

mccv1r0 commented Mar 28, 2019

/kind bug

podman does not add a CNI interface when one (or more) is specified via --network="netname"

Running a container without supplying --network on the command line works. When explicitly supplying CNI network to use (or needing to supply more than one) no interface is added to the container.

Steps to reproduce the issue:

  1. sudo podman run --network="podman" image

Describe the results you received:

Container created with just loopback interface

Describe the results you expected:

Container created with e.g. eth0, eth1 etc.

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

This is a regression. It worked on Fedora 28 just a week ago.

Output of podman version:

$ podman version 
Version:            1.1.2
RemoteAPI Version:  1
Go Version:         go1.10.8
Git Commit:         ff1bf1d7cb7f6f4e948e5419cca9bb48d38eddd1
Built:              Tue Mar  5 13:12:40 2019
OS/Arch:            linux/amd64
$ 

Output of podman info --debug:

$ podman info --debug
debug:
  compiler: gc
  git commit: ff1bf1d7cb7f6f4e948e5419cca9bb48d38eddd1
  go version: go1.10.8
  podman version: 1.1.2
host:
  BuildahVersion: 1.7.1
  Conmon:
    package: podman-1.1.2-1.git0ad9b6b.fc28.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: ff1bf1d7cb7f6f4e948e5419cca9bb48d38eddd1'
  Distribution:
    distribution: fedora
    version: "28"
  MemFree: 609026048
  MemTotal: 16452026368
  OCIRuntime:
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
      spec: 1.0.1-dev
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 4
  hostname: mcambria.redhat.com
  kernel: 4.20.16-100.fc28.x86_64
  os: linux
  rootless: true
  uptime: 32h 14m 18.72s (Approximately 1.33 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/mcambria/.config/containers/storage.conf
  ContainerStore:
    number: 2
  GraphDriverName: vfs
  GraphOptions: null
  GraphRoot: /home/mcambria/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 21
  RunRoot: /run/user/113799
  VolumePath: /home/mcambria/.local/share/containers/storage/volumes

$ 

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

Fedora 28

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 28, 2019
mheon added a commit to mheon/libpod that referenced this issue Mar 28, 2019
We accidentally patched this out trying to enable ns:/path/to/ns

This should restore the ability to configure nondefault CNI
networks with Podman, by ensuring that they request creation of a
network namespace.

Completely remove the WithNetNS() call when we do use an explicit
namespace from a path. We use that call to indicate that a netns
is going to be created - there should not be any question about
whether it actually does.

Fixes containers#2795

Signed-off-by: Matthew Heon <[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 24, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
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

No branches or pull requests

2 participants