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
There was a typo with the buildmode flag for containerd
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 5e4885b9afb1de30133627ce751af2c0e7b72a4e
Component: engine
These were originally static binaries in the first place, this changes
them back to that.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 63c7bb24637fdbfd905096ecc75b435ecefd31e9
Component: engine
To avoid noise in sampling CPU usage metrics, we now sample the system
usage closer to the actual response from the underlying runtime. Because
the response from the runtime may be delayed, this makes the sampling
more resilient in loaded conditions. In addition to this, we also
replace the tick with a sleep to avoid situations where ticks can backup
under loaded conditions.
The trade off here is slightly more load reading the system CPU usage
for each container. There may be an optimization required for large
amounts of containers but the cost is on the order of 15 ms per 1000
containers. If this becomes a problem, we can time slot the sampling,
but the complexity may not be worth it unless we can test further.
Unfortunately, there aren't really any good tests for this condition.
Triggering this behavior is highly system dependent. As a matter of
course, we should qualify the fix with the users that are affected.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Upstream-commit: fd0e24b7189374e0fe7c55b6d26ee916d3ee1655
Component: engine
Sorting by mount point length can be implemented in a more
straightforward fashion since Go 1.8 introduced sort.Slice()
with an ability to provide a less() function in place.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: a00310b54c0cdcafb402aeea92feca865da9fdf3
Component: engine
This makes `go test .` to pass if run as non-root user, skipping
those tests that require superuser privileges (for `mount`).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 4aae77602a7540b4f977572f3fbdc0891ac57cab
Component: engine
Layer metadata storage has not been implemented outside of the layer
store and will be deprecated by containerd metadata storage. To prepare
for this and freeze the current metadata storage, remove the exported
interface and make it internal to the layer store.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Upstream-commit: 0aebcbc32dc6a7b35982a2bfc44335562cbb68ec
Component: engine
The TestAPIServiceUpdatePort test performs exactly
the same steps.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 36e1646e4f010ea033643c6df3d9c3dccc166ed2
Component: engine
