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
This test is testing if any "no space left on device" errors
that occur during `docker pull` will not be masked by other
errors. To test for this, a new loopback-device was created,
and used as `--data-dir` ("/var/lib/docker").
However, `/var/lib/docker` is used for storing various
other things, including a `cache.db` database, used by
BuildKit, which is created during startup of the daemon.
Creation of that file failed (due to `--data-dir` path
being on a mount with limited size), which caused daemon
start to fail before the test was able to run.
This patch changes the size-limited mount to be used for
the storage-driver directory only, so that the test is
not affected by other parts of the code attempting to
write files in it.
To have a predictable path; the daemon used in this test
is configured to use the `vfs` storage-driver.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 754aeb28fdb9dd3aafb7705224e57f28281db264
Component: engine
Mainly to get inline with `docker/cli` version of that dependency
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: f929f15dd6e316402394143eeb60ad9ba95a81cb
Component: engine
Begin to copy the data until the command to exit and any coping to
stdin or copy from stdout/stderr has completed.
Also adding defense code to trim the possible '\x00' null value.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Upstream-commit: 386e0f36c42593ef434517448ccfac5262f958d6
Component: engine
This cleans up some of the package API's used for interacting with
volumes, and simplifies management.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e4b6adc88e967971de634596654d9bc33e7bd7e0
Component: engine
remove unnescessary import aliases, brackets, and so on.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f23c00d8701e4bd0f2372a586dacbf66a26f9a51
Component: engine
The following failure is seen in CI from time to time:
> FAIL: docker_api_containers_test.go:435: DockerSuite.TestContainerAPITop
>
> docker_api_containers_test.go:453:
> c.Assert(top.Processes[0][10], checker.Equals, "/bin/sh -c top")
> ... obtained string = "top"
> ... expected string = "/bin/sh -c top"
The test case expects two processes in the output:
1. /bin/sh -c top
2. top
in the given order.
Now, "ps aux" output is sorted by PID*, and so since the "top" is a child
of "/bin/sh -c top" it has a higher PID and will come second as expected
by the test... unless the PIDs on the system are exhausted and PID rollover
happens, in which case PID of "top" will be lower than that of "/bin/sh".
Fix: sort output by process name.
* - in fact it is not sorted, but is being printed in the same order as
the kernel list PID entries in /proc directory, which appears to be
sorted by PID (see ls -1 -U /proc).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 0823ab70990fa4cbf520726013e75c264e6c5231
Component: engine
