Revendors swarmkit with a change that fixes a rare segfault that can
occur when following logs on a brand new service with bad bind mount
options.
Fixesdocker/swarmkit#2147
Signed-off-by: Drew Erny <drew.erny@docker.com>
The source of a tag operation is allowed to be a 64-character hex
string. This means it should use ParseAnyReference for validation
instead of ParseNormalizedNamed.
This fixes a regression that happened in 17.04.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
(cherry picked from commit 4a0704cdbd)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
bash-completion script for 'docker build --network' calls
__docker_plugins, the correct name for this function is
__docker_plugins_bundled.
Closes#32588
Signed-off-by: Corey Farrell <git@cfware.com>
(cherry picked from commit eede2056fe)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Implements the following new CLI features:
- service logs is no longer experimental
- service logs also accepts task IDs
Signed-off-by: Harald Albers <github@albersweb.de>
(cherry picked from commit 47615c9b9b)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
In some cases, if a user specifies `-f` when disabling a plugin mounts
can still exist on the plugin rootfs.
This can cause problems during upgrade where the rootfs is removed and
may cause data loss.
To resolve this, ensure the rootfs is unmounted
before performing an upgrade.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 83f44d232d)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Since the certificate may be renewed multiple times, this check is
necessary.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
(cherry picked from commit 2b5ef9bfef)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Also fixed some examples of using `docker build` to clarify that the
positional argument is a directory, not a file.
Also fixed some terminology. Dockerfiles contain instructions, not directives or
commands.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
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>
