Libcontainer no longer provides placeholders for
unsupported platforms, which cause the Windows
builds to fail.
This patch moves features that are not supported
to platform-specific files.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
BusyBox v1.26.2 (2017-03-09 00:04:38 UTC) supports `-le` option
to get the full date and time information, while BusyBox v1.27.2
(2017-11-01 23:22:25 UTC, which is used by the official multi-arch
image, uses `--full-time` instead of `-e` to get the same data. As
a result, we will get below error for the `DockerSuite.TestBuildLastModified`
test case in case of multi-arch image used:
> docker_cli_build_test.go:446:
> out2 = cli.DockerCmd(c, "run", name, "ls", "-le", "/file").Combined()
> o/src/github.com/docker/docker/vendor/github.com/gotestyourself/gotestyourself/icmd/command.go:61:
> t.Fatalf("at %s:%d - %s\n", filepath.Base(file), line, err.Error())
> ... Error: at cli.go:33 -
> Command: /usr/local/bin/docker run testbuildlastmodified ls -le /file
> ExitCode: 1
> Error: exit status 1
> Stdout:
> Stderr: ls: invalid option -- e
> BusyBox v1.27.2 (2017-11-01 23:22:25 UTC) multi-call binary.
This PR tries to fix the above compatible issue for busybox image.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
We don't need the test image namespace anymore since we've already
upgrade those images to the latest multi-arch ones.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
I got the following test failure on power:
10:00:56
10:00:56
----------------------------------------------------------------------
10:00:56 FAIL: docker_cli_build_test.go:3521:
DockerSuite.TestBuildNotVerboseFailureRemote
10:00:56
10:00:56 docker_cli_build_test.go:3536:
10:00:56 c.Fatal(fmt.Errorf("Test[%s] expected that quiet stderr and
verbose stdout are equal; quiet [%v], verbose [%v]", name,
quietResult.Stderr(), result.Combined()))
10:00:56 ... Error: Test[quiet_build_wrong_remote] expected that quiet
stderr and verbose stdout are equal; quiet [
10:00:56 unable to prepare context: unable to download remote context
http://something.invalid: Get http://something.invalid: dial tcp: lookup
something.invalid on 172.29.128.11:53: no such host
10:00:56 ], verbose [unable to prepare context: unable to download
remote context http://something.invalid: Get http://something.invalid:
dial tcp: lookup something.invalid on 8.8.8.8:53: no such host
10:00:56 ]
10:00:56
10:00:56
10:00:56
----------------------------------------------------------------------
The reason is, either more than one name server is configured, or
nameserver was reconfigured in the middle of the test run. In any case,
different nameserver IP in an error messages should not be treated
as a failure, so let's strip those out.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
`TestCleanupMountsAfterDaemonAndContainerKill` was supposedly written
when the container mounts were visible from the host. Currently they
all live in their own mount namespace and the only visible mount is
the tmpfs one for shareable /dev/shm inside the container (i.e.
/var/lib/docker/containers/<ID>/shm), which will no longer be there
in case of `--default-ipc-mode private` is used, and so the test will
fail. Add a check if any container mounts are visible from the host,
and skip the test if there are none, as there's nothing to check.
`TestCleanupMountsAfterDaemonCrash`: fix in a similar way, keeping
all the other checks it does, and skipping the "mounts gone" check
if there were no mounts visible from the host.
While at it, also fix the tests to use `d.Kill()` in order to not
leave behind a stale `docker.pid` files.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. The functionality of this test is superceded by
`TestAPIIpcModeShareableAndContainer` (see
integration-cli/docker_api_ipcmode_test.go).
2. This test won't work with --default-ipc-mode private.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The building machinery was being handed an uninitialized container
Config. This changes it to use the target container's Config.
Resolves#30538
Signed-off-by: Anthony Sottile <asottile@umich.edu>
This test was added a long time ago, and over the years has proven to be flaky,
and slow. To address those issues, it was modified to;
- cleanup containers afterwards
- take clock-skew into account
- improve performance by parallelizing the container runs
- _reduce_ parallelization to address platform issues on Windows (twice..)
- adjust the test to take new limits into account
- adjust the test to account for more events being generated by containers
The last change to this test (made in ddae20c032) actually
broke the test, as it's now testing that all events sent by containers
(`numContainers*eventPerContainer`) are received, but the number of events that
is generated (17 containers * 7 events = 119) is less than the limit (256 events).
The limit is already covered by the `TestLogEvents` unit-test, that was added in
8d056423f8, and tests that the number of events
is limited to `eventsLimit`.
This patch removes the test, because it's not needed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Follow the conventions for namespace naming set out by other projects,
such as linuxkit and cri-containerd. Typically, they are some sort of
host name, with a subdomain describing functionality of the namespace.
In the case of linuxkit, services are launched in `services.linuxkit`.
In cri-containerd, pods are launched in `k8s.io`, making it clear that
these are from kubernetes.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Seen failing on Windows:
22:27:52 ----------------------------------------------------------------------
22:27:52 PANIC: docker_api_logs_test.go:152: DockerSuite.TestLogsAPIUntil
22:27:52
22:27:52 ... Panic: runtime error: index out of range (PC=0x45AC01)
22:27:52
22:27:52 d:/CI/CI-7caa30e89/go/src/runtime/asm_amd64.s:509
22:27:52 in call32
22:27:52 d:/CI/CI-7caa30e89/go/src/runtime/panic.go:491
22:27:52 in gopanic
22:27:52 d:/CI/CI-7caa30e89/go/src/runtime/panic.go:28
22:27:52 in panicindex
22:27:52 docker_api_logs_test.go:175
22:27:52 in DockerSuite.TestLogsAPIUntil
22:27:52 d:/CI/CI-7caa30e89/go/src/runtime/asm_amd64.s:509
22:27:52 in call32
22:27:52 d:/CI/CI-7caa30e89/go/src/reflect/value.go:434
22:27:52 in Value.call
22:27:52 d:/CI/CI-7caa30e89/go/src/reflect/value.go:302
22:27:52 in Value.Call
22:27:52 c:/gopath/src/github.com/docker/docker/vendor/github.com/go-check/check/check.go:816
22:27:52 in suiteRunner.forkTest.func1
22:27:52 c:/gopath/src/github.com/docker/docker/vendor/github.com/go-check/check/check.go:672
22:27:52 in suiteRunner.forkCall.func1
22:27:52 d:/CI/CI-7caa30e89/go/src/runtime/asm_amd64.s:2337
22:27:52 in goexit
22:27:54
22:27:54 ----------------------------------------------------------------------
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `repository:shortid` syntax for referencing images is very little used,
collides with with tag references can be confused with digest references.
The `repository:shortid` notation was deprecated in Docker 1.13 through
5fc71599a0, and scheduled for removal
in Docker 17.12.
This patch removes the support for this notation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `docker info` command compares the installed version
of containerd using a Git-sha. We currently use a tag for
this, but that tag is not returned by the version-API of
containerd, resulting in the `docker info` output to show:
containerd version: 89623f28b87a6004d4b785663257362d1658a729 (expected: v1.0.0)
This patch changes the `v1.0.0` tag to the commit that
corresponds with the tag, so that the `docker info` output
does not show the `expected:` string.
This should be considered a temporary workaround; the check
for the exact version of containerd that's installed was needed
when we still used the 0.2.x branch, because it did not have
stable releases yet.
With containerd reaching 1.0, and using SemVer, we can likely
do a comparison for "Major" version, or make this a "packaging"
issue, and remove the check entirely (we can still _print_ the
version that's installed if we think it's usefule).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit ee594dcb7d removed the
`sleep 0.5` from this test, because sleep has a full-second
precision. However, in some cases, all three log-entries
are output at the same time, causing the `--until` filter
to fail.
This patch adds back a `sleep`, but uses 1 second instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Interacting with v1 registries was deprecated in Docker 1.8.3, disabled by default
in Docker 17.06, and scheduled for removal in Docker 17.12.
This patch disallows enabling V1 registry through the `--disable-legacy-registry`
option, and the `"disable-legacy-registry": false` option in the daemon configuration
file. The actual V1 registry code is still in place, and will be removed separately.
With this patch applied:
$ dockerd --disable-legacy-registry=false
ERROR: The '--disable-legacy-registry' flag has been removed. Interacting with legacy (v1) registries is no longer supported
Or, when setting through the `daemon.json` configuration file
$ mkdir -p /etc/docker/
$ echo '{"disable-legacy-registry":false}' > /etc/docker/daemon.json
$ dockerd
ERROR: The 'disable-legacy-registry' configuration option has been removed. Interacting with legacy (v1) registries is no longer supported
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This sleep probably doesn't work because sleep typically takes only
whole numbers, to do < 1s you need to use usleep. It also is not really
needed as the loop has a very low bound that will not eat up too much
CPU.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The error type libnetwork.ErrNoSuchNetwork is used in the controller
to retry the network creation as a managed network though the manager.
The change of the type was breaking the logic causing the network to
not being created anymore so that no new container on that network
was able to be launched
Added unit test
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
Plugin config can have Mounts without a 'Source' field. In such cases,
performing a 'plugin set' on the mount source will panic the daemon. Its
the same case for device paths as well. This detects the case and
returns error.
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Support for duplicate labels (but different values) was
deprecated in commit e4c9079d09
(Docker 1.13), and scheduled for removal in 17.12
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
/dev is mounted on a tmpfs inside of a container. Processes inside of containers
some times need to create devices nodes, or to setup a socket that listens on /dev/log
Allowing these containers to run with the --readonly flag makes sense. Making a tmpfs
readonly does not add any security to the container, since there is plenty of places
where the container can write tmpfs content.
I have no idea why /dev was excluded.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If the user specifies a mountpath from the host, we should not be
attempting to chown files outside the daemon's metadata directory
(represented by `daemon.repository` at init time).
This forces users who want to use user namespaces to handle the
ownership needs of any external files mounted as network files
(/etc/resolv.conf, /etc/hosts, /etc/hostname) separately from the
daemon. In all other volume/bind mount situations we have taken this
same line--we don't chown host file content.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
