Update docs for dockerd.md about `max-concurrent-downloads/max-concurrent-uploads`
Upstream-commit: 0fb23fb6bc59f406a7e532385f27e31374260966
Component: engine
It seems that `max-concurrent-downloads` and `max-concurrent-uploads`
are supported in Windows for `config.json`. Though that was not
mentioned in the docs for dockerd.md.
This fix adds the following to the example `config.json` file for Windows:
```
"max-concurrent-downloads": 3,
"max-concurrent-uploads": 5,
```
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 1f660febbd114f40e5232ba3137ac4f912ab53cc
Component: engine
--group-add was used for specifying groups for both service create
and service update. For create it was confusing since we don't have
an existing set of groups. Instead I added --group to create, and
moved --group-add to service update only, like --group-rm
This deals with issue 27646
Signed-off-by: Lily Guo <lily.guo@docker.com>
Update flag documentation
Specify that --group, --group-add and --groupd-rm refers to
supplementary user groups
Signed-off-by: Lily Guo <lily.guo@docker.com>
Fix docs for groups and update completion scripts
Signed-off-by: Lily Guo <lily.guo@docker.com>
Upstream-commit: 2f58494ae6e796325329f849cf547bcf94bb68e3
Component: engine
When converting an opaque directory always keep the original
directory tar entry to ensure directory is created with correct
permissions on restore.
Closes#27298
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Upstream-commit: daa70195171d798cdfb6c4033b33a06a8f7ebe6c
Component: engine
Right now we do have a problem to store the .debs for raspbian-jessie and
debian-jessie distro version for armhf arch. Both .debs have the same filename
so we have to include the distro version, too.
Signed-off-by: Dieter Reuter <dieter.reuter@me.com>
Upstream-commit: 8b8d27fb7878874f6309ec8bb1ab7b967ec5ea1b
Component: engine
As for `ps`, `images`, `network ls` and `volume ls`, this makes it
possible to define a custom default format.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 12cae3a590a92f0d908c03c172aec974957b3785
Component: engine
When daemon fails to load an authz plugin, it should be removed from
the plugin list. Else the plugin is retried on every request and
response, resulting in undesired behavior (eg. daemon panic)
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: fae904af02a184833d2cd5ce9fdd61a4083707c7
Component: engine
A HealthConfig entry was added to the ContainerSpec associated with the
service being created or updated.
Signed-off-by: Cezar Sa Espinola <cezarsa@gmail.com>
Upstream-commit: 7bd2611789e6898576f7229255c238f7c1129293
Component: engine
fmt package formats an error by calling its Error() method.
This results in recursion. Fix this. Also remove dead code.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 4db753c0174420152957224d38fb6e8b6ae6908e
Component: engine
This makes possible to use IPv6 addresses in the `--publish` flag of
docker (`run`, …)
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 609c183ae7092c60b61021e61f181ae67dea331a
Component: engine
Many distributions now use ext4 to provide ext2 and ext3 support,
so do not warn about possibly missing ext3 support if the config
option is used.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: b28619046a92977f33be6b3ddba5e60c589b3c0f
Component: engine
Fixes#27779
Currently `followLogs` can get into a deadlock if we receive an inotify
IN_MODIFY event while we are trying to close the `fileWatcher`. This is
due to the fact that closing the `fileWatcher` happens in the same block
as consumes events from the `fileWatcher`. We are trying to run
`fileWatcher.Close`, which is waiting for an IN_IGNORE event to come in
over inotify to confirm the watch was been removed. But, because an
IN_MODIFY event has appeared after `Close` was entered but before the
IN_IGNORE, the broadcast never comes. The IN_MODIFY cannot be consumed
as the events channel is unbuffered and the only `select` that reads
from it is busy waiting for the IN_IGNORE event.
In order to try and fix this race condition I've moved the removal of
the `fileWatcher` out to a separate go block that waits for a signal to
close, removes the watcher and then signals to the previous selects on
the close signal.
This has introduced a `fileWatcher.Remove` in the final case, but if we
try and remove a watcher that does not exist it will just return an
error saying so. We are not doing any checking on the return of `Remove`
so this shouldn't cause any side-effects.
Signed-off-by: Tom Booth <tombooth@gmail.com>
Upstream-commit: a69a59ffc7e3d028a72d1195c2c1535f447eaa84
Component: engine
Sebastiaan van Stijn
Yong Tang
Michael Crosby
Lily Guo
Derek McGowan
Victor Vieux
Vincent Demeester
Misty Stanley-Jones
Josh Horwitz
John Howard
John Howard
Darren Stahl
Brian Goff
Dieter Reuter
Anusha Ragunathan
Cezar Sa Espinola
yuexiao-wang
boucher
Justin Cormack
Harald Albers
Tom Booth
Akihiro Suda
Steve Durrheimer
Yanqiang Miao