Inconsistent behavior of --network option

[kriansa]

Issue Description

For the scope of this bug report, consider network list as a list of named bridged networks created previously, separated by commas. Example: mynetwork1,mynetwork2

Currently, when creating and running containers passing a network list on the --network option works. I can't say "as expected", because that's not officially documented anywhere, although I have seen mentions of this format in various places. In fact, the doc says:

Use the --network option multiple times to specify additional networks.

So I assume that a network list is not a canonical form of how this option works. Is that correct?

I understand that removing this behavior is probably a breaking change and would need to be shipped on the next major.

However, considering that there's an intention to support this format moving forward, then let me present you the bug report below:

When using create or run with multiple --network options and at least one of these options is a network list, then:

1. You can't pass more than one list (i.e. multiple --network options with a list in it) -- it fails with Error: unable to find network with name or ID network1,network2: network not found
2. You can't pass a list after you passed a non-list option. For instance --network net1,net2 --network net3 would work, but --network net1 --network net2,net3 wouldn't

Steps to reproduce the issue

Steps to reproduce the issue

1. podman run --rm --network podman,podman --network podman alpine:latest ls will work
2. podman run --rm --network podman --network podman,podman alpine:latest ls will not work

Describe the results you received

First one will work, but the second one will not.

Describe the results you expected

I honestly don't know because this is not documented anywhere.

podman info output

host:
  arch: amd64
  buildahVersion: 1.30.0
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.1.7-1
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: f633919178f6c8ee4fb41b848a056ec33f8d707d'
  cpuUtilization:
    idlePercent: 97.79
    systemPercent: 0.87
    userPercent: 1.34
  cpus: 12
  databaseBackend: boltdb
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  hostname: daniel-laptop.lan.cx
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 10000
      size: 65536
  kernel: 6.3.9-arch1-1
  linkmode: dynamic
  logDriver: journald
  memFree: 5133987840
  memTotal: 33395511296
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: /usr/bin/crun is owned by crun 1.8.5-1
    path: /usr/bin/crun
    version: |-
      crun version 1.8.5
      commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
      rundir: /run/user/1000/crun
      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: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: /usr/bin/slirp4netns is owned by slirp4netns 1.2.0-1
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 34359734272
  swapTotal: 34359734272
  uptime: 81h 33m 22.00s (Approximately 3.38 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/dpereira/.config/containers/storage.conf
  containerStore:
    number: 8
    paused: 0
    running: 0
    stopped: 8
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/dpereira/.local/share/containers/storage
  graphRootAllocated: 253702758400
  graphRootUsed: 161720512512
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 799
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/dpereira/.local/share/containers/storage/volumes
version:
  APIVersion: 4.5.1
  Built: 1685139594
  BuiltTime: Fri May 26 19:19:54 2023
  GitCommit: 9eef30051c83f62816a1772a743e5f1271b196d7-dirty
  GoVersion: go1.20.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.1

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

N/A

Additional information

N/A

[Luap99]

This only kept for backwards compat, multiple networks should be specified with multiple --network options. Before 4.0 you had to specify the network names comma separated but now commas are used for extra network options as described in the man page.

Because this syntax is deprecated it is not mentioned in the doc.

But the fact that you can specify the same network name more than once definitely looks like a bug to me. It should error out ideally but I guess this would be a breaking change now.