You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tests TestDockerNetworkIPAMOptions and TestDockerNetworkCustomIPAM are flucky
In our runs of docker integration tests (docker running in Virtuozzo system-containers) we see that testsuite can hang on those testcases until timeout (for a couple of hours).
Steps to reproduce the issue:
It reproduces sometimes in our normal test runs, so it reproduces with only:
make test-integration-cli
But to make reproduce 100% one can just do:
# Prepare docker development container (checkout v20.10.5)
make BIND_DIR=. shell
# Prepare dockerd inside
hack/make.sh binary install-binary
dockerd -D &>daemon.log &
# Create bridge with addr 172.28.0.1/16
ip link add name my_bridge type bridge
ip addr add dev my_bridge 172.28.0.1/16
ip link set my_bridge up
# Run test
TESTFLAGS='-test.run DockerNetworkSuite/TestDockerNetworkIPAMOptions' hack/make.sh test-integration-cli
Describe the results you received:
The test TestDockerNetworkIPAMOptions would hang forever on docker network create --ipam-driver dummy-ipam-driver ...
Describe the results you expected:
No hang.
Additional information you deem important (e.g. issue happens only occasionally):
That is because docker daemon would be busy-looping in requestPoolHelper trying to get pool, get pool "172.28.0.0/16" from dummyIPAMDriver, and netutils.FindAvailableNetwork would detect that pool overlaps with existing device address.
On actual reproduce (with make test-integration-cli) the address is held by some bridge leftover from swarm testsuite:
72: docker_gwbridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:0d:75:2a:14 brd ff:ff:ff:ff:ff:ff
inet 172.28.0.1/16 brd 172.28.255.255 scope global docker_gwbridge
valid_lft forever preferred_lft forever
I've seen an ooold issue moby/libnetwork#1386 about this but it was just closed. Probably we should not retry forever and have some timeout for request pool operation, or at least fix "dummy" somehow to use different IP in case it is intersecting with something?
Output of docker version:
# docker --version
Docker version 20.10.5, build 55c4c88
Please don't mind kernel version, Virtuozzo kernel is RHEL7 based + many container related patches, we also run docker integration tests as you can see =). Synthetic reproduce should be working everywhere.
The text was updated successfully, but these errors were encountered:
Description
Tests TestDockerNetworkIPAMOptions and TestDockerNetworkCustomIPAM are flucky
In our runs of docker integration tests (docker running in Virtuozzo system-containers) we see that testsuite can hang on those testcases until timeout (for a couple of hours).
Steps to reproduce the issue:
It reproduces sometimes in our normal test runs, so it reproduces with only:
But to make reproduce 100% one can just do:
Describe the results you received:
The test TestDockerNetworkIPAMOptions would hang forever on
docker network create --ipam-driver dummy-ipam-driver ...
Describe the results you expected:
No hang.
Additional information you deem important (e.g. issue happens only occasionally):
That is because docker daemon would be busy-looping in requestPoolHelper trying to get pool, get pool "172.28.0.0/16" from dummyIPAMDriver, and netutils.FindAvailableNetwork would detect that pool overlaps with existing device address.
On actual reproduce (with
make test-integration-cli
) the address is held by some bridge leftover from swarm testsuite:With dlv I can see stacks like:
and
I've seen an ooold issue moby/libnetwork#1386 about this but it was just closed. Probably we should not retry forever and have some timeout for request pool operation, or at least fix "dummy" somehow to use different IP in case it is intersecting with something?
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):
Please don't mind kernel version, Virtuozzo kernel is RHEL7 based + many container related patches, we also run docker integration tests as you can see =). Synthetic reproduce should be working everywhere.
The text was updated successfully, but these errors were encountered: