`docker compose config` returns "undefined network default" error when service uses `default` network and `--compatibility` is applied

[eliottwiener]

Description

When a service uses the default network, calling docker compose --compatibility config returns an error like:

service ... refers to undefined network default: invalid compose project

Steps to reproduce the issue:

1. Create a compose file called example.yml that contains the following:

services:
  helloworld:
    image: helloworld
    networks:
      default:

2. Run docker compose --compatibility --file example.yml --project-name myproject config

Describe the results you received:

An error is emitted:

service "helloworld" refers to undefined network default: invalid compose project

Describe the results you expected:

compose should output the effective configuration:

services:
  helloworld:
    image: helloworld
    networks:
      default: null
networks:
  default:
    name: myproject_default

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

This works as expected in v2.1.1 . I was able to determine via git bisect that this regression was introduced with d00eacbba06dffec7d9c3a55ec2a6e5e647fa8a0, from #8943.

Additionally, it should be noted that compose-switch passes --compatibility as of docker/compose-switch#21 (included in v1.0.3).

Output of docker compose version:

Docker Compose version v2.2.2

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.7.0-10-gab73275f.m)
  compose: Docker Compose (Docker Inc., v2.2.2)
  scan: Docker Scan (Docker Inc., v0.9.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.0-9-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.55GiB
 Name: ...
 ID: RFDS:PPSP:TOKV:SUYH:M5CB:QGBG:63EO:4HYM:5BX4:FYHX:OFSM:LK44
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: eliottwiener
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

[cdavernas]

Facing the exact same issue here, with following docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.1)
  scan: Docker Scan (Docker Inc., 0.9.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 13
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.4.72-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 7.689GiB
 Name: docker-desktop
 ID: 3R7B:QKPR:V4KB:JG3I:WA2N:NGG4:XLNK:DS46:XXFB:CRIR:YI72:M7JF
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support

[ndeloof]

right, as we skip normalization, we don't declare the implicit default network anymore. question: why do you explicitly assign your services to networks: default, as .. you don't need to!

[cdavernas]

@ndeloof Well, as far as I know, you do need to specify default for services that are using multiple networks, so they are still able to communicate with other services residing on the default's. Am I missing something?

[ndeloof]

right, good point

[BlackthornYugen]

This issue hits me too. I need to specify default as well as other shared networks that are defined.

[mmrko]

Same here, we reference default for specifying aliases.

[pabloroman]

Same problem here. Has anyone found a workaround yet?

[eliottwiener]

@pabloroman There are some workarounds to try, depending on how you are using compose and what your needs are:

1. Downgrade to v2.1.1

2. Include the default network explicitly in the networks section:

services:
  helloworld:
    image: helloworld
    networks:
      default: null
networks:
  default:
    name: myproject_default

3. Omit the --compatibility option. If you are calling compose via compose-switch (e.g. if you are calling docker-compose instead of docker compose), then --compatibility may be applied. You may not need this option.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.