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
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
Scripts were changed around to do static by default, this changes so
that we have "dynamic" inserted where it needs to be inserted
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 130f74155e39ddc36b59d7c47867230284739710
Component: packaging
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
