The hardcoded values make it so that we have to update this everytime we
add/subtract something which is sometimes followed/not followed.
This makes it so that we no longer have to update this.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 04ec3b020edc79830c5a0100790f5bb6686d8efc
Component: packaging
Fedora 26 will be EOL one month after the release of Fedora 28
(2018-05-01)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: c638836c18d26c5f7e4602784d6b1c7d13f39904
Component: packaging
In cases where a logging plugin has crashed when the daemon tries to
copy the container stdio to the logging plugin it returns a broken pipe
error and any log entries that occurr while the plugin is down are lost.
Fix this by opening read+write in the daemon so logs are not lost while
the plugin is down.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e7479e3ab8128f9e84cc640f0bed4e77b268a6e9
Component: engine
- Check errors.Cause(err) when comparing errors
- Fix bug where oldest log file is not actually removed. This in
particular causes issues when compression is enabled. On rotate it just
overwrites the data in the log file corrupting it.
- Use O_TRUNC to open new gzip files to ensure we don't corrupt log
files as happens without the above fix.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e87e9e6ad6ba501cc42a2ef47ac18c88a68f258f
Component: engine
Closing the log driver was in a defer meanwhile logs are
collected asyncronously, so the log driver was being closed before reads
were actually finished.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2c252a48c252749d41079cf8c450d00a5c18296e
Component: engine
This was broken by bf6a790f00ab96bb8857e3c73502909ee5e36217
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b16b125bb4326e2eec9948fd54ca8c5d83eba36a
Component: engine
In TestDockerNetworkConnectAlias the network and container
names used are unique which are not preferred. This
fix address the issue by appending t.Name() so that
names are randomized.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: e7b5f4500dc77ec55e5ef202065fbc92218ce394
Component: engine
This message was missing the name of the plugin, resulting in
plugin_test.go:92: timeout hit after 30s: plugin %!q(MISSING) exists
On failing tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b526964584d213074de7c5573a3373a58699c181
Component: engine
Embedded new lines aren't interpreted correctly in markdown renderers (they are treated as preformatted text instead). I removed the embedded newlines in the docker image spec.
Signed-off-by: Alex Goodman <wagoodman@gmail.com>
Upstream-commit: 4fb59c20a4fb54f944fe170d0ff1d00eb4a24d6f
Component: engine
In version-history.md, the link for `Docker Engine API v1.37`
was pointed to `v1.36`.
This fix fixes the incorrect link.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 6d66743ae3da148adbd29fb7e0c0433e93fec12b
Component: engine
This fix re-orders the CHANGELOG so that `make validate` test
could pass. The validation requires that the date in the changelog
is always ordered.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 333693c37c8a2c14458d2a088829b9a2a3570eed
Component: engine
Switch from x/net/context to context made "go vet" see the previously
unseen errors:
> cli/command/container/start.go:57::error: the cancelFun function is
> not used on all paths (possible context leak) (vet)
> cli/command/container/start.go:63::error: this return statement may be
> reached without using the cancelFun var defined on line 57 (vet)
> cli/command/container/run.go:159::error: the cancelFun function is not
> used on all paths (possible context leak) (vet)
> cli/command/container/run.go:164::error: this return statement may be
> reached without using the cancelFun var defined on line 159 (vet)
Do call the cancel function.
Note we might end up calling it twice which is fine as long as I can see
from the Go 1.10 source code.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 395957155f
Component: cli
Since go 1.7, "context" is a standard package. Since go 1.9,
x/net/context merely provides some types aliased to those in
the standard context package.
The changes were performed by the following script:
for f in $(git ls-files \*.go | grep -v ^vendor/); do
sed -i 's|golang.org/x/net/context|context|' $f
goimports -w $f
for i in 1 2; do
awk '/^$/ {e=1; next;}
/\t"context"$/ {e=0;}
{if (e) {print ""; e=0}; print;}' < $f > $f.new && \
mv $f.new $f
goimports -w $f
done
done
[v2: do awk/goimports fixup twice]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 6f8070deb2
Component: cli
Removing a host by `<host>:<ip>` should only remove occurences of the host with
a matching IP-address, instead of removing all entries for that host.
In addition, combining `--host-rm` and `--host-add` for the same host should
result in the new host being added.
This patch fixes the way the diff is calculated to allow combining
removing/adding, and to support entries having both a canonical, and aliases.
Aliases cannot be added by the CLI, but are supported in the Service spec, thus
should be taken into account:
Entries can be removed by either a specific `<host-name>:<ip-address>`
mapping, or by `<host>` alone:
- If both IP-address and host-name is provided, only remove the hostname
from entries that match the given IP-address.
- If only a host-name is provided, remove the hostname from any entry it
is part of (either as _canonical_ host-name, or as _alias_).
- If, after removing the host-name from an entry, no host-names remain in
the entry, the entry itself should be removed.
For example, the list of host-entries before processing could look like this:
hosts = &[]string{
"127.0.0.2 host3 host1 host2 host4",
"127.0.0.1 host1 host4",
"127.0.0.3 host1",
"127.0.0.1 host1",
}
Removing `host1` removes every occurrence:
hosts = &[]string{
"127.0.0.2 host3 host2 host4",
"127.0.0.1 host4",
}
Whereas removing `host1:127.0.0.1` only remove the host if the IP-address matches:
hosts = &[]string{
"127.0.0.2 host3 host1 host2 host4",
"127.0.0.1 host4",
"127.0.0.3 host1",
}
Before this patch:
$ docker service create --name my-service --host foo:127.0.0.1 --host foo:127.0.0.2 --host foo:127.0.0.3 nginx:alpine
$ docker service update --host-rm foo:127.0.0.1 --host-add foo:127.0.0.4 my-service
$ docker service inspect --format '{{.Spec.TaskTemplate.ContainerSpec.Hosts}}' my-service
[]
After this patch is applied:
$ docker service create --name my-service --host foo:127.0.0.1 --host foo:127.0.0.2 --host foo:127.0.0.3 nginx:alpine
$ docker service update --host-rm foo:127.0.0.1 --host-add foo:127.0.0.5 my-service
$ docker service inspect --format '{{.Spec.TaskTemplate.ContainerSpec.Hosts}}' my-service
[127.0.0.2 foo 127.0.0.3 foo 127.0.0.4 foo]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 27c0858f43
Component: cli
This function was added in 23e5c94cfb26eb72c097892712d3dbaa93ee9bc0 but never used
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 8a8ec00c1fece033b20548b7a5ec2f3a1f340834
Component: engine
The overlay storage driver currently does not support any option, but was silently
ignoring any option that was passed.
This patch verifies that no options are passed, and if they are passed will produce
an error.
Before this change:
dockerd --storage-driver=overlay --storage-opt dm.thinp_percent=95
INFO[2018-05-11T11:40:40.996597152Z] libcontainerd: started new docker-containerd process pid=256
....
INFO[2018-05-11T11:40:41.135392535Z] Daemon has completed initialization
INFO[2018-05-11T11:40:41.141035093Z] API listen on /var/run/docker.sock
After this change:
dockerd --storage-driver=overlay --storage-opt dm.thinp_percent=95
INFO[2018-05-11T11:39:21.632610319Z] libcontainerd: started new docker-containerd process pid=233
....
Error starting daemon: error initializing graphdriver: overlay: unknown option dm.thinp_percent
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 30f15d2bdc551870464d1cd024a92341cf1ae4aa
Component: engine
The "update" and "rollback" configurations were cross-wired, as a result, setting
`--rollback-*` options would override the service's update-options.
Creating a service with both update, and rollback configuration:
docker service create \
--name=test \
--update-failure-action=pause \
--update-max-failure-ratio=0.6 \
--update-monitor=3s \
--update-order=stop-first \
--update-parallelism=3 \
--rollback-failure-action=continue \
--rollback-max-failure-ratio=0.5 \
--rollback-monitor=4s \
--rollback-order=start-first \
--rollback-parallelism=2 \
--tty \
busybox
Before this change:
docker service inspect --format '{{json .Spec.UpdateConfig}}' test \
&& docker service inspect --format '{{json .Spec.RollbackConfig}}' test
Produces:
{"Parallelism":3,"FailureAction":"pause","Monitor":3000000000,"MaxFailureRatio":0.6,"Order":"stop-first"}
{"Parallelism":3,"FailureAction":"pause","Monitor":3000000000,"MaxFailureRatio":0.6,"Order":"stop-first"}
After this change:
{"Parallelism":3,"FailureAction":"pause","Monitor":3000000000,"MaxFailureRatio":0.6,"Order":"stop-first"}
{"Parallelism":2,"FailureAction":"continue","Monitor":4000000000,"MaxFailureRatio":0.5,"Order":"start-first"}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f367aa9330
Component: cli