Codecov Report

Merging #37371 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #37371      +/-   ##
==========================================
- Coverage   34.95%   34.94%   -0.01%     
==========================================
  Files         609      609              
  Lines       44832    44832              
==========================================
- Hits        15669    15666       -3     
- Misses      27051    27053       +2     
- Partials     2112     2113       +1

Pushed a 2nd commit to adjust a unit test that employed overlapping subnets.

The TestDockerNetworkIPAMMultipleNetworks test allocates several networks simultaneously with overlapping IP addresses. Libnetwork now forbids this.

This may be a breaking change for people using that as a feature, or did this never work properly?

@abhi and @fcrisciani can elaborate, but as I understand it this did not work properly, especially for swarm. In swarm mode it would accept the configuration as allowable, but when trying to create tasks in a service it would fail the network allocation and just leave the service pretty much in limbo.

@thaJeztah do you know the real use case/history of overlapping subnet ?
In swarm we fail overlapping subnets but we do not fail "exact" subnets for 2 different networks. It was working behind the scenes because it was using the pool id. But in libnetwork this has not been fully implemented e2e though it can be supported. This was causing some silent errors as well. So we make sure if its overlapping subnet we just error it out.

Not sure if there's a real use case (as in "need to have these networks in the same range"), but (just from the top of my head) thinking of users that have a template / compose file to create networks with an IP-range, and may be using the same template / compose file for multiple stacks.

PowerPC failure looks unrelated; there was an old issue for this test #34988, but should've been fixed by #35173.

Not sure if it's a different issue now

20:51:35 FAIL: check_test.go:347: DockerSwarmSuite.TearDownTest
20:51:35 
20:51:35 check_test.go:352:
20:51:35     d.Stop(c)
20:51:35 /go/src/github.com/docker/docker/internal/test/daemon/daemon.go:401:
20:51:35     t.Fatalf("Error while stopping the daemon %s : %v", d.id, err)
20:51:35 ... Error: Error while stopping the daemon d96103a2b0b0e : exit status 130
20:51:35 
20:51:35 
20:51:35 ----------------------------------------------------------------------
20:51:35 PANIC: docker_api_swarm_test.go:359: DockerSwarmSuite.TestAPISwarmRaftQuorum
20:51:35 
20:51:35 [d96103a2b0b0e] waiting for daemon to start
20:51:35 [d96103a2b0b0e] daemon started
20:51:35 
20:51:35 [dec520e876db4] waiting for daemon to start
20:51:35 [dec520e876db4] daemon started
20:51:35 
20:51:35 [d6bfca0b0791f] waiting for daemon to start
20:51:35 [d6bfca0b0791f] daemon started
20:51:35 
20:51:35 [dec520e876db4] exiting daemon
20:51:35 [d6bfca0b0791f] exiting daemon
20:51:35 [dec520e876db4] waiting for daemon to start
20:51:35 [dec520e876db4] daemon started
20:51:35 
20:51:35 [d96103a2b0b0e] daemon started
20:51:35 Attempt #2: daemon is still running with pid 7420
20:51:35 Attempt #3: daemon is still running with pid 7420
20:51:35 Attempt #4: daemon is still running with pid 7420
20:51:35 [d96103a2b0b0e] exiting daemon
20:51:35 ... Panic: Fixture has panicked (see related PANIC)

@thaJeztah I am not sure if someone would intentionally use the subnet for multiple networks unless they used it accidentally ?

Agreed that it could be accidentally; curious: what happens with existing networks (that have overlapping subnets) after upgrading?

Discussing this with @fcrisciani and @ctelfer; although a corner-case, there may be users out there that currently have overlay network that have an overlapping subnet; for those, it will be needed to re-create the network, so for Docker we need a mention in the changelog