In case of failure, stale out was printed.
Fixes: 6212ea669b4e92b3
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 1921753b4b30dcca4fe772e7c1b0bc3f7bb7cd62)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b60ecd32a1d3ba7debf02d15fe346ea5ca607bbd
Component: engine
Move the test case from integration-cli to integration.
The test logic itself has not changed, except these
two things:
* the new test sets default-ipc-mode via command line
rather than via daemon.json (less code);
* the new test uses current API version.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 9fd765f07cc08ccc2ea991d21835bf50ece9318b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b228a498d55fcd47c741d51a510a7f5eab0794f7
Component: engine
This test sometimes failed because the number of events received did not
match the expected number:
FAIL: docker_cli_events_test.go:316: DockerSuite.TestEventsFilterLabels
docker_cli_events_test.go:334:
c.Assert(len(events), checker.Equals, 3)
... obtained int = 2
... expected int = 3
This patch makes the test more stable, by:
- use a wider range between `--since` and `--until`. These options were set
so that the client detaches after events were received, but the actual
range should not matter. Changing the range will cause more events to be
returned, but we're specifically looking for the container ID's, so this
should not make a difference for the actual test.
- use `docker create` instead of `docker run` for the containers. the
containers don't have to be running to trigger an event; using `create`
speeds up the test.
- check the exit code of the `docker create` to verify the containers were
succesfully created.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0e15c02465c87c82908bcc45b0c1d6bd38f27c32)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 26f7e0a8b08b2890d079d4083735c05377770ca8
Component: engine
I noticed that this test failed, because the node was in status "pending".
The test checks for the node's status immediately after it was restarted, so
possibly it needs some time to unlock.
14:07:10 FAIL: docker_cli_swarm_test.go:1128: DockerSwarmSuite.TestSwarmLockUnlockCluster
...
14:07:10 docker_cli_swarm_test.go:1168:
14:07:10 checkSwarmLockedToUnlocked(c, d)
14:07:10 docker_cli_swarm_test.go:1017:
14:07:10 c.Assert(getNodeStatus(c, d), checker.Equals, swarm.LocalNodeStateActive)
14:07:10 ... obtained swarm.LocalNodeState = "pending"
14:07:10 ... expected swarm.LocalNodeState = "active"
This patch adds a `waitAndAssert` for the node's status, with a 1 second timeout.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 973ca00d60712ef644b5b37abf7fa01078bb4ade)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 954425f8bdb5db95355cb20be465d248f7c3b1f1
Component: engine
When starting docker daemons for swarm testing, we disable iptables
and use lo for communication (in order to avoid network conflicts).
The problem is, these options are lost on restart, that can lead
to any sorts of network conflicts and thus connectivity issues
between swarm nodes.
Fix this. This does not fix issues with swarm test failures, but
it seems they appear are less often after this one.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 2ed512c7faea938b0b07e69187b8a132e2ecb66a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 553b09684cb68962403ebdc5495fb548364f778f
Component: engine
This is repeated 6 times in different tests, with slight
minor variations. Let's factor it out, for clarity.
While at it, simplify the code: instead of more complex
parsing of "docker swarm init|update --autolock" output (1)
and checking if the key is also present in
"docker swarm unlock-key" output (2), get the key
from (2) and check it is present in (1).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 24cbb9897193894f4716583d1861091ab2fa1ae2)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 6ec991ec8371bdba94480c587eea6ea24f3e9d43
Component: engine
Since commit 17173efbe00 checkSwarmLockedToUnlocked() no longer
require its third argument, so remove it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 66cb1222d6559e120d9d1a29932aa778aa517894)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 2a02a2e9dae0045d550e98fa849aceafc0c41a0e
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
(cherry picked from commit b1b9937bc75f0db9c804838ecce9bb6792a42525)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 533b0f602d10af8fe325c3544a2411f5060a47b8
Component: engine
It looks like the logic of the test became wrong after commit
ae0883c ("Move TestAttachDetach to integration-cli").
The original logic was:
* (a few first steps skipped for clarity)
* send escape sequence to "attach";
* check "attach" is exiting (i.e. escape sequence works);
* check the container is still alive;
* kill the container.
Also, timeouts were big at that time, in the order of seconds.
The logic after the above mentioned commit and until now is:
* ...
* send escape sequence to "attach";
* check the container is running (why shouldn't it?);
* kill the container;
* checks that the "attach" has exited.
So, from the "let's check detach using escape sequence is working"
the test became something like "let's check that attach is gone
once we kill the container".
Let's fix the above test, also increasing the timeout waiting
for attach to exit (which fails from time to time on power CI).
Now, the second test, TestAttachDetachTruncatedID, does the exact
same thing, except it uses a truncated container ID. It does not
seem to be of much value, so let's remove it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 9f3a343a5101ab661a6a97c9e149a0b11ccc320a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 17ae129697c10e9f866ffc253bc211f8912588df
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit 9d2e97ac6e20b17477947fc63e70299938606a38)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 91703956dffcf1d9c997aea83f9489a8c768412d
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
(cherry picked from commit 80fce6d747c5208b42e94ac9e3f22cef28dd8afe)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fd4670161de8f9947c524138c477177f935c98f2
Component: engine
Signed-off-by: John Howard <jhoward@microsoft.com>
This is a follow-on from https://github.com/moby/moby/pull/38277
but had to be done in a couple of stages to ensure that CI didn't
break. v1.1 of the busybox image is now based on a CMD of "sh"
rather than using an entrypoint. And it also uses the bin directory
rather than `c:\busybox`. This makes it look a lot closer to the
Linux busybox image, and means that a couple of Windows-isms in
CI tests can be reverted back to be identical to their Linux
equivalents.
(cherry picked from commit 561e0f6b7fc256c160292b32695cf1d6150741db)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 613c2f27ed2e7d65474c2f3e786d9e24e757d99d
Component: engine
- TestAPISwarmLeaderElection
- TestAPISwarmRaftQuorum
- TestSwarmClusterRotateUnlockKey
because they are known to be flaky.
Signed-off-by: Olli Janatuinen <olli.janatuinen@gmail.com>
(cherry picked from commit 02157c638ba0c325d8fd1debc1678e7e99eacfc1)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 278f1a130b66de23f07e472792b70b640f777666
Component: engine
RHEL/CentOS 3.10 kernels report that kernel-memory accounting is supported,
but it actually does not work.
Runc (when compiled for those kernels) will be compiled without kernel-memory
support, so even though the daemon may be reporting that it's supported,
it actually is not.
This cause tests to fail when testing against a daemon that's using a runc
version without kmem support.
For now, skip these tests based on the kernel version reported by the daemon.
This should fix failures such as:
```
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_run_unix_test.go:499: DockerSuite.TestRunWithKernelMemory
assertion failed:
Command: /usr/bin/docker run --kernel-memory 50M --name test1 busybox cat /sys/fs/cgroup/memory/memory.kmem.limit_in_bytes
ExitCode: 0
Error: <nil>
Stdout: 9223372036854771712
Stderr: WARNING: You specified a kernel memory limit on a kernel older than 4.0. Kernel memory limits are experimental on older kernels, it won't work as expected and can cause your system to be unstable.
Failures:
Expected stdout to contain "52428800"
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:125: DockerSuite.TestUpdateKernelMemory
/go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:136:
...open /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go: no such file or directory
... obtained string = "9223372036854771712"
... expected string = "104857600"
----------------------------------------------------------------------
FAIL: /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:139: DockerSuite.TestUpdateKernelMemoryUninitialized
/go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go:149:
...open /go/src/github.com/docker/docker/integration-cli/docker_cli_update_unix_test.go: no such file or directory
... value = nil
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1e1156cf67233cf8eaee2da9c17465ff0d9c2aa0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: e042692db1316a60be35bfdca10d7e08d20f50ad
Component: engine
These messages were enhanced to include the path that was
missing (in df6af282b9048dfedcd7b7a9a89126aca887f4e1), but
also changed the first part of the message.
This change complicates running e2e tests with mixed versions
of the engine.
Looking at the full error message, "mount" is a bit redundant
as well, because the error message already indicates this is
about a "mount";
docker run --rm --mount type=bind,source=/no-such-thing,target=/foo busybox
docker: Error response from daemon: invalid mount config for type "bind": bind mount source path does not exist: /no-such-thing.
Removing the "mount" part from the error message, because
it was redundant, and makes cross-version testing easier :)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 574db7a53782c57554089c9606505af1c108df0b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b499acc0e834e11882909269238407c65f68f034
Component: engine
This allows to run the daemon in environments that have upstream containerd installed.
Signed-off-by: Tibor Vass <tibor@docker.com>
(cherry picked from commit 34eede0296bce6a9c335cb429f10728ae3f4252d)
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: b3bb2aabb8ed5a8af0a9f48fb5aba3f39af38e0d
Component: engine
1. After running d.Cmd(), in case an error is returned, it makes sense
to print command output, as its stderr may contain a clue about what
went wrong. This is by no means complete, just as far as I could go.
2. In case the comment in c.Assert is a constant string, it's better
to provide it as a comment which will be printed.
3. An arbitrary string should not be passed on to a function expecting
%-style formatting. Use %s to fix this.
4. Print the output string before transformation, not after.
5. Unify the output format (drop "out:" prefix").
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: ac038eab298eeecab55a62440de302e3bb3f4889
Component: engine
It is wrong to pass an arbitrary string to a function expecting
%-style formatting. One solution would be to replace any % with %%,
but it's easier to just do what this patch does.
Generated with:
for f in $(git grep -l 'check.Commentf(out)'); do \
sed -i -e 's/check\.Commentf(out)/check.Commentf("%s", out)/g' $f; \
done
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 83363fb2d4d97d952a0052d079faa8ae39aa20b6
Component: engine
This fix migrates some ipc container tests from integration-cli
to integration test.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 80c92c9b692b79273200b6e37f14a6d4e984ab8d
Component: engine
fix the race condition in the integration test TestRunContainerWithBridgeNone
Upstream-commit: 9149ef67be8ac945d68fafb16a1aa4ccb2f72249
Component: engine
moved integration tests from docker_cli_config_create_test.go to integration/config
Upstream-commit: a5495f289aafafac8a01c62f2a9cb44856658ece
Component: engine
Instead of waiting for the DNS to fail, try to access
a specific external IP and verify that 100% of the pakcets
are being lost.
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
Upstream-commit: a2bb2144b3e0d49ac615976bfac462a307d85f0e
Component: engine
This fix migrates some ipcmode tests in integration-cli
to integration tests.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: e0403604e26868b1546a766ab0b40b6cb1677ee6
Component: engine
The TestDockerNetworkIPAMMultipleNetworks test allocates several
networks simultaneously with overlapping IP addresses. Libnetwork now
forbids this. Adjust the test case to use distinct IP ranges for the
networks it creates.
Signed-off-by: Chris Telfer <ctelfer@docker.com>
Upstream-commit: efb7909befa0fe2236148543a6d50e2563bf386c
Component: engine
