Bring in:
- moby 36517 ensure hijackedConn implements CloseWrite function
- moby 36489 (fixes `errdefs.ErrSystem` interface)
- moby 36506 pkg/mount: use sort.Slice
- moby 36451 Windows: Report Version and UBR
Also update moby dependencies to keep them in sync
- golang.org/x/sync (no code changes)
- Bump runc to 4fc53a81fb7c994640722ac585fa9ca548971871
- Bump swarmkit to 49a9d7f6ba3c1925262641e694c18eb43575f74b
no local code changes
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b17215c456
Component: cli
The `docker trust` commands were moved out of experimental,
and the `docker trust view` command was changed to
`docker trust inspect --pretty`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 2a6808db87
Component: cli
With the ticker this could end up just doing back-to-back checks, which
isn't really what we want here.
Instead use a sleep to ensure we actually sleep for the desired
interval.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 04a0d6b863ed50cfffa79936cf9cdab7a3a9e7df
Component: engine
In info, we only need the number of images, but `CountImages` was
getting the whole map of images and then grabbing the length from that.
This causes a lot of unnecessary CPU usage and memory allocations, which
increases with O(n) on the number of images.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: f6a7763b6f3256bed9a7352021745189d0ca8dc9
Component: engine
I noticed this test failed on Windows:
> 17:46:24 docker_cli_run_test.go:4361:
> 17:46:24 c.Fatal("running container timed out") // cleanup in teardown
I also noticed that in general tests are running slower on Windows,
for example TestStartAttachSilent (which runs a container with
`busybox echo test` and then starts it again) took 29.763s.
This means a simple container start can easily take 15s, which
explains the above failure.
Double the timeout from 15s to 30s.
Fixes: 4e262f6387 ("Fix race on sending stdin close event")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 5043639645123f2728c81c9a55fea525475ec324
Component: engine
I am not quite sure why but this test is sometimes failing like this:
> 15:21:41 --- FAIL: TestLinksEtcHostsContentMatch (0.53s)
> 15:21:41 assertions.go:226:
>
> Error Trace: links_linux_test.go:46
> 15:21:41
> Error: Not equal:
> 15:21:41
> expected: "127.0.0.1\tlocalhost\n::1\tlocalhost
> ip6-localhost
> ip6-loopback\nfe00::0\tip6-localnet\nff00::0\tip6-mcastprefix\nff02::1\tip6-allnodes\nff02::2\tip6-allrouters\n172.17.0.2\tf53feb6df161\n"
> 15:21:41
> received: ""
To eliminate some possible failures (like ignoring stderr from `cat` or
its exit code), let's use container.Exec() to read a file from a container.
Fixes: e6bd20edcbf ("Migrate some integration-cli test to api tests")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: ad2f88d8ccbd9dd0a8d9c4f96ece3956f60489df
Component: engine
As mentioned in commit 9e31938, test cases that use t.Parallel()
and start a docker daemon might step on each other toes as they
try to configure iptables during startup, resulting in flaky tests.
To avoid this, --iptables=false should be used while starting daemon.
Fixes: eaa5192856c1 ("Make container resource mounts unbindable")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: c125e10a0486623ba3badebf974ea6e582373151
Component: engine
Ingress networks will no longer automatically remove their
load-balancing endpoint (and sandbox) automatically when the network is
otherwise upopulated. This is to prevent automatic removal of the
ingress networks when all the containers leave them. Therefore
explicit removal of an ingress network also requires explicit removal
of its load-balancing endpoint.
Signed-off-by: Chris Telfer <ctelfer@docker.com>
Upstream-commit: 3da4ebf355d3494d1403b2878a1ae6958b2724e9
Component: engine
This PR prevents automatic removal of the load balancing sandbox
endpoint when the endpoint is the last one in the network but
the network is marked as ingress.
Signed-off-by: Chris Telfer <ctelfer@docker.com>
Upstream-commit: bebad150c9c3bc6eb63758c10ef24b9298ecf6e2
Component: engine
The commit https://github.com/moby/moby/pull/35422 had the result of
accidentally causing the removal of the ingress network when the
last member of a service left the network. This did not appear
in swarm instances because the swarm manager would still maintain
and return cluster state about the network even though it had
removed its sandbox and endpoint. This test verifies that after a
service gets added and removed that the ingress sandbox remains
in a functional state.
Signed-off-by: Chris Telfer <ctelfer@docker.com>
Upstream-commit: 805b6a7f749a6c7cbb237e21ee7260d536621808
Component: engine
Since now we have only one Dockerfile, so the arch-specific suffix
of the Dockerfile is not needed anymore.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Upstream-commit: 8eb7ed673b687ae17e2c7df5dd40f8081c299bc2
Component: engine
Removing all the existing arch-specific Dockerfiles since we already
have a new multi-arch supported one as the replacement.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Upstream-commit: 162f9aee476bd204c2b0146c0128949182e8bd5e
Component: engine
This PR consolidates the existing arch-specific Dockerfiles into only
one file `Dockefile` to ease the code maintenance effort.
Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Upstream-commit: f1701a741d77a92d28138944193e23aabfc74abe
Component: engine
These tests were enabled by changing a config option on the ci
machines, instead of from a patch, so let me disable them
for now on ppc64le and open up another patch to enable them, where I can find
out what the issues are with them.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: 620ddc78a1437feaa42f40853ef586d268991620
Component: engine
It has been pointed out that if --read-only flag is given, /dev/shm
also becomes read-only in case of --ipc private.
This happens because in this case the mount comes from OCI spec
(since commit 7120976d74195), and is a regression caused by that
commit.
The meaning of --read-only flag is to only have a "main" container
filesystem read-only, not the auxiliary stuff (that includes /dev/shm,
other mounts and volumes, --tmpfs, /proc, /dev and so on).
So, let's make sure /dev/shm that comes from OCI spec is not made
read-only.
Fixes: 7120976d74195 ("Implement none, private, and shareable ipc modes")
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: cad74056c09f6276b0f4a996a1511553177cd3d7
Component: engine
The test case checks that in case of IpcMode: private and
ReadonlyRootfs: true (as in "docker run --ipc private --read-only")
the resulting /dev/shm mount is NOT made read-only.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 33dd562e3acff71ee18a2543d14fcbecf9bf0e62
Component: engine
Remove the global variable used. Allows easier unit testing.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 6e21829af4
Component: cli
