This fix is part of the effort to address 30242 where
issue arise because of the fact that multiple networks
may share the same name (within or across local/swarm scopes).
The focus of this fix is to allow creation of service
when a network in local scope has the same name as the
service network.
An integration test has been added.
This fix fixes 30242.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: cafed80cd019a8b40025eaa5e5b37459362607fb
Component: engine
The event filter used two separate filter-conditions for
"namespace" and "topic". As a result, both events matching
"topic" and events matching "namespace" were subscribed to,
causing events to be handled both by the "plugin" client, and
"container" client.
This patch rewrites the filter to match only if both namespace
and topic match.
Thanks to Stephen Day for providing the correct filter :)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 295bb09184fe473933498bb0efb59b8acb124f55
Component: engine
Further to 355cf9483c1b8ede5ae3ed50add4de2a69d62645 which caught some
of these. This should fix the remainder in the contributing docs.
Signed-off-by: Brett Randall <javabrett@gmail.com>
Upstream-commit: e96b33665e58f73a16923b89a9bcc6fe6fcdb6c6
Component: engine
According to https://github.com/golang/go/issues/5373, go recognizes
(and optimizes for) the following syntax:
```go
for i := range b {
b[i] = 0
}
```
so let's use it. Limited testing shows ~7.5x speed increase,
compared to the previously used syntax.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: f0cab0e28512de5eecc0412212425cc74d62af71
Component: engine
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>
Upstream-commit: 3676bd8569f4df28a4f850cd4814e3558d8c03f6
Component: engine
`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>
Upstream-commit: f5e01452d2c2a07bab48b4e05306ef9446770c4a
Component: engine
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>
Upstream-commit: 519c06607ca7e8a544afddbd61ad57afe63a98b4
Component: engine
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>
Upstream-commit: 0785836c4b440a8d4a5dfdb8df82e50f9f4d23a1
Component: engine
The `Status` field was deprecated in favor of `Action`.
This patch updates the test to use the `Action` field,
but adds a check that both are set to the same value.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b7d204ef6b1b2d6a3bafb42f844cdc146976e68f
Component: engine
Commit 59d45c384a2de7bca73296ce1471646db14cb0c8 changed
the `eventsLimit` from 64 to 256, but did not update
the GoDoc accordingly.
This patch updates the GoDoc for `Subscribe` and `SubscribeTopic`
to match the actual limit.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fb3935022dbc160fc1531fa43f0ca2db69184800
Component: engine
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 ddae20c032058a0fd42c34c2e9750ee8f62) 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
8d056423f8c433927089bd7eb6bc97abbc1ed502, 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>
Upstream-commit: b7ad3e7ea10e285226a0a5b1665e8205b3264128
Component: engine
When compiling containerd binaries statically, linker rightfully
complains:
+ make BUILDTAGS=static_build 'EXTRA_FLAGS=-buildmode pie' 'EXTRA_LDFLAGS=-extldflags "-fno-PIC -static"'
🇩 bin/ctr
# github.com/containerd/containerd/cmd/ctr
/tmp/go-link-343047789/000000.o: In function `_cgo_b0c710f30cfd_C2func_getaddrinfo':
/tmp/go-build/net/_obj/cgo-gcc-prolog:46: warning: Using 'getaddrinfo'
in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
The same error appears for ctr, containerd, and containerd-stress
binaries.
The fix is to use Go's own DNS resolver functions, rather than
glibc's getaddrinfo() -- this option is turned on by `netgo` build tag.
See https://golang.org/pkg/net/ (look for "Name Resolution") for more
details.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 7368ef96c89fd4f6879addf5214c4a09889a05be
Component: engine
This is a fix to regression in vfs graph driver introduced by
commit 7a1618ced359a3ac92 ("add quota support to VFS graphdriver").
On some filesystems, vfs fails to init with the following error:
> Error starting daemon: error initializing graphdriver: Failed to mknod
> /go/src/github.com/docker/docker/bundles/test-integration/d6bcf6de610e9/root/vfs/backingFsBlockDev:
> function not implemented
As quota is not essential for vfs, let's ignore (but log as a warning) any error
from quota init.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 1e8a087850aa9f96c5000a3ad90757d2e9c0499f
Component: engine
Revendor swarmkit to 713d79dc8799b33465c58ed120b870c52eb5eb4f to include
https://github.com/docker/swarmkit/pull/2473.
Signed-off-by: Marcus Martins <marcus@docker.com>
Upstream-commit: af73d31e60fd5c26d58bb8275785e628c3febdc0
Component: engine
