integration/networking: increase context timeout for attach#50347
integration/networking: increase context timeout for attach#50347thaJeztah merged 1 commit intomoby:masterfrom
Conversation
The TestNatNetworkICC and TestFlakyPortMappedHairpinWindows (TestPortMappedHairpinWindows)
tests were frequently failing on Windows with a context timeout;
=== FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC/User_defined_nat_network (9.67s)
nat_windows_test.go:62: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/4357bd24c9b77b955ee961530d1f552ce099b3dcbeb396db599971b2396d8b08/start": context deadline exceeded
panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network mynat has active endpoints (name:"ctr2" id:"dc8d597dafef")
=== FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC (18.34s)
=== FAIL: github.com/docker/docker/integration/networking TestFlakyPortMappedHairpinWindows (13.02s)
nat_windows_test.go:110: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/65207ae3d6953d85cd2123feac45af60b059842d570d4f897ea53c813cba3cb4/start": context deadline exceeded
panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network clientnet has active endpoints (name:"amazing_visvesvaraya" id:"18add58d415e")
These timeouts were set in c1ab6ed and
2df4391, and were shared between Linux
and Windows; likely Windows is slower to start, so these timeouts to be
expected.
Let's increase the context timeout to give it a bit more time.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
|
Ugh ... hitting this one again; And ... of course .. LOL |
robmry
left a comment
There was a problem hiding this comment.
LGTM - thank you ... I'm not sure why the cleanup fails (after the timeout) in TestFlakyPortMappedHairpinWindows, the network is deleted eventually. But, it's a separate issue.
Wondering as well; possibly it could be a race because of this? (container eventually starts, but not (yet) removed or something silly. We should probably still dig in, but hopefully this reduces some of the issues. |
Yes, it must be something like that ... by the time the test tear-down runs the container must have exited, so its extra network-delete call succeeds. |
relates to:
The TestNatNetworkICC and TestFlakyPortMappedHairpinWindows (TestPortMappedHairpinWindows) tests were frequently failing on Windows with a context timeout;
These timeouts were set in c1ab6ed and 2df4391, and were shared between Linux and Windows; likely Windows is slower to start, so these timeouts to be expected.
Let's increase the context timeout to give it a bit more time.
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)