- When a network is created with the null ipam driver, docker api server
thread will deference a nil pointer on `docker network ls` and on
`docker network inspect <nw>`. This because buildIpamResource()
assumes a gateway address is always present, which is not correct.
Signed-off-by: Alessandro Boch <aboch@tetrationanalytics.com>
Upstream-commit: beebfc0cf6240c8af511eb4d7e29314c8de6ddf2
Component: engine
Changes most references of syscall to golang.org/x/sys/
Ones aren't changes include, Errno, Signal and SysProcAttr
as they haven't been implemented in /x/sys/.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
[s390x] switch utsname from unsigned to signed
per 33267e036f
char in s390x in the /x/sys/unix package is now signed, so
change the buildtags
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: 069fdc8a083cb1663e4f86fe3fd9b9a1aebc3e54
Component: engine
These replace `wait*` functions from `docker_utils_test.go` and work
more or less like other `cli` functions.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: db35c2a5a8d93cfeac9e75a3add60ae7c64a5856
Component: engine
When a container was being destroyed was possible to have
flows in conntrack left behind on the host.
If a flow is present into the conntrack table, the packet
processing will skip the POSTROUTING table of iptables and
will use the information in conntrack to do the translation.
For this reason is possible that long lived flows created
towards a container that is destroyed, will actually affect
new flows incoming to the host, creating erroneous conditions
where traffic cannot reach new containers.
The fix takes care of cleaning them up when a container is
destroyed.
The test of this commit is actually reproducing the condition
where an UDP flow is established towards a container that is then
destroyed. The test verifies that the flow established is gone
after the container is destroyed.
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
Upstream-commit: 1c4286bcffcdc6668f84570a2754c78cccbbf7e1
Component: engine
There is 5 calls left, that use StdinPipe that is not yet supported by
icmd.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: ecbb0e62f66da7d698c4f4583f36b927d8cfa811
Component: engine
to make goreportcard a bit happier
https://goreportcard.com/report/github.com/docker/docker
also found that `TestCpToErrDstParentNotExists()` was
partially broken, because a `runDockerCp()` was inadvertently
removed in f26a31e80cfcc77daba0872ddb14bf03f4398311
`TestDaemonRestartSaveContainerExitCode()` didn't verify
the actual _Error_ message, so added that to the test,
and updated the test to take into account that the
"experimental" CI enables `--init` on containers.
`TestVolumeCLICreateOptionConflict()` only checked
for an error to occur, but didn't validate if the
error was due to conflicting options.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: ba0afd70e89562aa3c668c87fb9191ed9edb7260
Component: engine
There is still ways to go
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 87e3fcfe1e059780c4ee57abb097296fd29e09af
Component: engine
Move plugins to shared distribution stack with images.
Create immutable plugin config that matches schema2 requirements.
Ensure data being pushed is same as pulled/created.
Store distribution artifacts in a blobstore.
Run init layer setup for every plugin start.
Fix breakouts from unsafe file accesses.
Add support for `docker plugin install --alias`
Uses normalized references for default names to avoid collisions when using default hosts/tags.
Some refactoring of the plugin manager to support the change, like removing the singleton manager and adding manager config struct.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Upstream-commit: 3d86b0c79b16334ce5836c0315e4c310b84c2e17
Component: engine
Due to the test plugins being architecture specific, these
tests fail to start the plugin (even though they don't fail yet)
Temporary fix until we can build architecture specific test
plugins.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: ebff8c79a3b834c555f92e673c604f14fa0afa33
Component: engine
… to make sure it doesn't fail. It also introduce StartWithError,
StopWithError and RestartWithError in case we care about the
error (and want the error to happen).
This removes the need to check for error and make the intent more
clear : I want a deamon with busybox loaded on it — if an error occur
it should fail the test, but it's not the test code that has the
responsability to check that.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: c502fb49dc7af89adfb2a9686354aa78c2c46002
Component: engine
SetupTest could fail creating a Daemon object (eg, out of space when
creating daemon root dir). In such a case, TearDownTest fails when
accessing the daemon object. This commit adds the required nil check.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 5890091cc02ca75425c8635cbe4ec6c7ccd1663b
Component: engine
Since the plugin APIs have not changed for local-scoped network drivers
between plugin-v1 and v2, a simple test to validate the bootstrapping
and network creation APIs would suffice.
Any network driver specific API validations are handled independent of
plugin v1 or v2 format.
Using a sample v2 network plugin :
https://github.com/mavenugo/test-docker-netplugin/
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 259441c027226683d38080caac7a39d6192c9dfa
Component: engine
No substantial code change.
- Api --> API
- Cli --> CLI
- Http, Https --> HTTP, HTTPS
- Id --> ID
- Uid,Gid,Pid --> UID,PID,PID
- Ipam --> IPAM
- Tls --> TLS (TestDaemonNoTlsCliTlsVerifyWithEnv --> TestDaemonTLSVerifyIssue13964)
Didn't touch in this commit:
- Git: because it is officially "Git": https://git-scm.com/
- Tar: because it is officially "Tar": https://www.gnu.org/software/tar/
- Cpu, Nat, Mac, Ipc, Shm: for keeping a consistency with existing production code (not changable, for compatibility)
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 7fb7a477d79c67ab53c432977780662ccbfeec57
Component: engine
Test is testing that a user can disconnect from the default network
before it is started (#26220).
This test does not need to use `--rm`, which is never aken into account
since the container is never started.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: f05ed0075893bb907b5cc2612d9193d775134e2d
Component: engine
This moves the types for the `engine-api` repo to the existing types
package.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 91e197d614547f0202e6ae9b8a24d88ee131d950
Component: engine
This fix tries to address the issue raised in 26220 where
disconnecting a container from network does not work if
the network id (instead of network name) has been specified.
The issue was that internally when trying to disconnecting
a contaienr fromt the network, the originally passed network
name or id has been used.
This fix uses the resolved network name (e.g., `bridge`).
An integration test has been added to cover the changes.
This fix fixes 26220.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 83d79f13aa2e94085e83e0f5bc5d51305dd2c192
Component: engine
This fix tries to address the issue raised in comment:
https://github.com/docker/docker/pull/25943#discussion_r76843081
Previously, the validation for `ip6` is done by checking ParseIP().To16().
However, in case an IPv4 address or an IPv4-mapped Ipv6 address has been
provided, the validation will pass (should fail).
This fix first check if `--ip6` is passed with a valid IP address and returns
error for invalid IP addresses. It then check if an IPv4 or IPv4-mapped Ipv6
address is passed, and return error accordingly.
This fix adds two more cases in the tests. One for IPv4 address passed to `--ip6`
and another for Ipv4-mapped IPv6 address passed to `--ip6`. In both cases,
without this fix the validation will pass through.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 1e6eccae69bd9b1f65ec87c33a6a872c81f7fb23
Component: engine
There are cases such as migrating from classic overlay network to the
swarm-mode networking (without kv-store), such a mechanism to allow
disconnecting a container even when a network isnt available will be
useful.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 05a3f2666ee34c2dfa04663bbdda3c7763b001d8
Component: engine
This fix tries to fix the issue raised in 25863 where `--ip` value
is not validated for `docker create`. As a result, the IP address
passed by `--ip` is not used for `docker create` (ignored silently).
This fix adds validation in the daemon so that `--ip` and `--ip6`
are properly validated for `docker create`.
An integration test has been added to cover the changes.
This fix fixes 25863.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: c7045eb93523df76feb9f3e00540e69471a1855e
Component: engine
Fix delete containers and make sure it prints errors correctly.
Rename Result.Fails to Result.Assert()
Create a constant for the default expected.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 243885808f5c69143679d094d964d333c47e69bf
Component: engine
Remove some run functions and replace them with the unified run command.
Remove DockerCmdWithStdoutStderr
Remove many duplicate runCommand functions.
Also add dockerCmdWithResult()
Allow Result.Assert() to ignore the error message if an exit status is expected.
Fix race in DockerSuite.TestDockerInspectMultipleNetwork
Fix flaky test DockerSuite.TestRunInteractiveWithRestartPolicy
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: d7022f2b46589cb9d860219e1d8278351ba147c3
Component: engine
Add a `--network` flag which replaces `--net` without deprecating it
yet. The `--net` flag remains hidden and supported.
Add a `--network-alias` flag which replaces `--net-alias` without deprecating
it yet. The `--net-alias` flag remains hidden and supported.
Signed-off-by: Arnaud Porterie (icecrime) <arnaud.porterie@docker.com>
Upstream-commit: c0c7d5e71586ec8e4d54aef9e061f061e9223cc4
Component: engine
