podman doesn't report host and null networks in API

[tkolo]

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

/kind bug

Description

This bug is about podman<->docker incompatibility.
When inspecting networks, docker lists two additional built-in networks that podman doesn't: host and null. While it's not a problem in tooling, same behavior occurs when querying network list via docker.scok. This poses a problem for certain integrations, currently I'm struggling with setting up home assistant supervisor on podman instead of docker. It crashes when trying to fetch host network

Steps to reproduce the issue:

1. Start podman service/enable podman.socket

2. curl --unix-socket /run/podman/podman.sock http://localhost/v1.41/networks/host

Describe the results you received:

{"cause":"network not found","message":"unable to find network with name or ID host: network not found","response":404}

Describe the results you expected:
A valid response describing host "network", per docker specs

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

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
b842d728e0fc   bridge    bridge    local
3d4820238ed4   host      host      local
10347eb3a565   none      null      local

vs

$ sudo podman network ls
NETWORK ID    NAME        DRIVER
2f259bab93aa  podman      bridge

Output of podman version:

Client:       Podman Engine
Version:      4.2.1
API Version:  4.2.1
Go Version:   go1.19
Git Commit:   62b324ddf718411b1d4d0ba8117c632f7f984a38-dirty
Built:        Thu Sep  8 09:39:42 2022
OS/Arch:      linux/arm64

Output of podman info:

host:
  arch: arm64
  buildahVersion: 1.27.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: /usr/bin/conmon is owned by conmon 1:2.1.4-1
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: bd1459a3ffbb13eb552cc9af213e1f56f31ba2ee'
  cpuUtilization:
    idlePercent: 99.03
    systemPercent: 0.62
    userPercent: 0.34
  cpus: 4
  distribution:
    distribution: archarm
    version: unknown
  eventLogger: journald
  hostname: yellowarch
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.72-1-rpi-ARCH
  linkmode: dynamic
  logDriver: journald
  memFree: 3263414272
  memTotal: 8127463424
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: /usr/bin/crun is owned by crun 1.6-1
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/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: false
    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: 0
  swapTotal: 0
  uptime: 6h 43m 12.00s (Approximately 0.25 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 7
    paused: 0
    running: 4
    stopped: 3
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 999130095616
  graphRootUsed: 2883391488
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 8
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.2.1
  Built: 1662622782
  BuiltTime: Thu Sep  8 09:39:42 2022
  GitCommit: 62b324ddf718411b1d4d0ba8117c632f7f984a38-dirty
  GoVersion: go1.19
  Os: linux
  OsArch: linux/arm64
  Version: 4.2.1

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

$ sudo pacman -Qi podman
Name            : podman
Version         : 4.2.1-1
Description     : Tool and library for running OCI-based containers in pods
Architecture    : aarch64
URL             : https://github.com/containers/podman
Licenses        : Apache
Groups          : None
Provides        : None
Depends On      : catatonit  conmon  containers-common  crun  iptables  libdevmapper.so=1.02-64  libgpgme.so=11-64  libseccomp.so=2-64  slirp4netns
Optional Deps   : apparmor: for AppArmor support [installed]
                  btrfs-progs: support btrfs backend devices [installed]
                  netavark: for a new container-network-stack implementation [installed]
                  podman-compose: for docker-compose compatibility [installed]
                  podman-docker: for Docker-compatible CLI
Required By     : podman-compose
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 64.04 MiB
Packager        : Arch Linux ARM Build System <[email protected]>
Build Date      : Thu Sep 8 09:39:42 2022
Install Date    : Fri Oct 7 19:32:41 2022
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

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

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

I'm using Arch Linux ARM aarch64 on raspberry pi CM4

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[lstolcman]

This happened to me when I tried to use podman together with docker-compose

I tried to run simple compose.yml:

services:
  base:
    image: alpine:latest
    command: sh -c "echo ok"

When I have podman as a backend, it gives the error:

$ docker-compose up
network example_default was found but has incorrect label com.docker.compose.network set to ""

I believe, the root cause is same as reported by @tkolo.

Rendering compose file (docker-compose config) shows that under the hood, docker-compose looks for "null" default network, which is not existing in podman:

name: example
services:
  base:
    command:
    - sh
    - -c
    - echo ok
    image: alpine:latest
    networks:
      default: null
networks:
  default:
    name: example_default

env:

• WSL2 1.3.11, ubuntu 22.04.2 LTS
• podman 4.5.1
• docker-compose 2.19.0

[rhatdan]

@Luap99 PTAL

[Luap99]

This happened to me when I tried to use podman together with docker-compose

I tried to run simple compose.yml:

services:
  base:
    image: alpine:latest
    command: sh -c "echo ok"

When I have podman as a backend, it gives the error:

$ docker-compose up
network example_default was found but has incorrect label com.docker.compose.network set to ""

I believe, the root cause is same as reported by @tkolo.

Rendering compose file (docker-compose config) shows that under the hood, docker-compose looks for "null" default network, which is not existing in podman:

name: example
services:
  base:
    command:
    - sh
    - -c
    - echo ok
    image: alpine:latest
    networks:
      default: null
networks:
  default:
    name: example_default

env:

* WSL2 1.3.11, ubuntu 22.04.2 LTS

* [podman 4.5.1](https://github.com/containers/podman)

* [docker-compose 2.19.0](https://github.com/docker/compose/releases/tag/v2.19.0)

This does not look related to this bug. Something wrong with labels but that compose file shouldn't use host or none network. Please file a separate bug.

[Luap99]

The problem here is we do not consider host or none real networks. There is nothing to do in the network backend. It is just a simple oci spec setting, no network setup is performed in these cases.

While we can fake these networks to be included in the compat api, the problem is there is no way for us to fake an actual ID. If a caller tries to use the ID we have to actually know that we should use none or host and with our current code structure this is not trivial to implement.

---

And also I have no idea what the linked HA code tries to do. You cannot disconnect the host network when the container uses host networking!

# docker network disconnect host c1
Error response from daemon: container cannot be disconnected from host network or connected to host network

I mean I understand that this is some weird workaround for a docker bug but logically doing this makes no sense and would cause an error in the disconnect call within podman as well so I am not sure if HA would fail because of that as well.

[tkolo]

I don't mind submitting an issue on their side as well asking for podman compatibility, or perhaps even attempt to fix the code myself, however a consensus on proper solution from podman's side first would be helpful

[Luap99]

It is reasonable to expect a fix on our side. We try to provide a compatible API but there are of course and we generally try to address them. That one here is just not so trivial and it is hard to find time to fix more complicated bugs.

If you could ask them about podman support that would help of course. As this seems to be a specific bug work around simply not calling that code for podman should be good enough I assume.

[nettnikl]

When I have podman as a backend, it gives the error:

$ docker-compose up
network test_default was found but has incorrect label com.docker.compose.network set to ""

Hey, didn't find the ticket you opened for this specific case, but to follow up on this: i had the same issue and it seemingly was caused by the network being still set up from my test environment from before i did the docker-compose test:

[
     {
          "name": "test_default",
          "id": "9a714d65cbfdc198416d32c9f0089fa446da433f7190773f5242da864ff3d28b",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2023-09-02T13:59:13.821470823+02:00",
          "subnets": [
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": false,
          "internal": false,
          "dns_enabled": true,
          "labels": {
               "com.docker.compose.project": "test",
               "io.podman.compose.project": "test"
          },
          "ipam_options": {
               "driver": "host-local"
          }
     }
]

Deleting the network (not just compose down) helped me.

env:
* podman 4.6.1
* docker-compose 2.20.3