--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>
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>
The --name flag was inadvertently added to
docker service update, but is not supported,
as it has various side-effects (e.g., existing
tasks are not renamed).
This removes the flag from the service update
command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
containers may specify these cgroup values at runtime. This will allow
processes to change their priority to real-time within the container
when CONFIG_RT_GROUP_SCHED is enabled in the kernel. See #22380.
Also added sanity checks for the new --cpu-rt-runtime and --cpu-rt-period
flags to ensure that that the kernel supports these features and that
runtime is not greater than period.
Daemon will support a --cpu-rt-runtime flag to initialize the parent
cgroup on startup, this prevents the administrator from alotting runtime
to docker after each restart.
There are additional checks that could be added but maybe too far? Check
parent cgroups to ensure values are <= parent, inspecting rtprio ulimit
and issuing a warning.
Signed-off-by: Erik St. Martin <alakriti@gmail.com>
Currently, there's no way to restart the tasks of a service without
making an actual change to the service. This leads to us giving awkward
workarounds as in
https://github.com/docker/docker.github.io/pull/178/files, where we tell
people to scale a service up and down to restore balance, or make
unnecessary changes to trigger a restart.
This change adds a --force option to "docker service update", which
forces the service to be updated even if no changes require that.
Since rolling update parameters are respected, the user can use
"docker service --force" to do a rolling restart. For example, the
following is supported:
docker service update --force --update-parallelism 2 \
--update-delay 5s myservice
Since the default value of --update-parallelism is 1, the default
behavior is to restart the service one task at a time.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Keeping the current behavior for exec, i.e., inheriting
variables from main process. New variables will be added
to current ones. If there's already a variable with that
name it will be overwritten.
Example of usage: docker exec -it -e TERM=vt100 <container> top
Closes#24355.
Signed-off-by: Jonh Wendell <jonh.wendell@redhat.com>
Unfortunately, `(f)` aka `(ps:\n:)` flag will not create an array when
there is only one line. The subsequent use of indexes will then affect
the string. This leads to `docker rmi <tab>` to complete on the header
line instead of nothing.
Therefore, for each use of `(f)`, we ensure that we have an extra new
line to be sure we get an array.
Credit to @povesteam for the original report and fix in #27373.
Signed-off-by: Vincent Bernat <vincent@bernat.im>
This adds support for two enhancements to swarm service rolling updates:
- Failure thresholds: In Docker 1.12, a service update could be set up
to either pause or continue after a single failure occurs. This adds
an --update-max-failure-ratio flag that controls how many tasks need to
fail to update for the update as a whole to be considered a failure. A
counterpart flag, --update-monitor, controls how long to monitor each
task for a failure after starting it during the update.
- Rollback flag: service update --rollback reverts the service to its
previous version. If a service update encounters task failures, or
fails to function properly for some other reason, the user can roll back
the update.
SwarmKit also has the ability to roll back updates automatically after
hitting the failure thresholds, but we've decided not to expose this in
the Docker API/CLI for now, favoring a workflow where the decision to
roll back is always made by an admin. Depending on user feedback, we may
add a "rollback" option to --update-failure-action in the future.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
When sending a build context to a remote server it may be
(significantly) advantageous to compress the build context. This commit
adds support for gz compression when constructing a build context
using a command like "docker build --compress ."
Signed-off-by: Paul Kehrer <paul.l.kehrer@gmail.com>
New driver options:
- `splunk-gzip` - gzip compress all requests to Splunk HEC
(enabled by default)
- `splunk-gzip-level` - change compression level.
Messages are sent in batches by 1000, with frequency of 5 seconds.
Maximum buffer is 10,000 events. If HEC will not be available, Splunk
Logging Driver will keep retrying while it can hold messages in buffer.
Added unit tests for driver.
Signed-off-by: Denis Gladkikh <denis@gladkikh.email>
`--log-opt splunk-format=inline|json|raw` allows to change how logging
driver sends data to Splunk, where
`inline` - default value, format used before, message is injected as a
line in JSON payload
`json` - driver will try to parse each line as a JSON object and embed it
inside of the JSON payload
`raw` - driver will send Raw payload instead of JSON, tag and attributes
will be prefixed before the message
`--log-opt splunk-verify-connection=true|false` - allows to skip
verification for Splunk Url
Signed-off-by: Denis Gladkikh <denis@gladkikh.email>
Steve Durrheimer
Akihiro Suda
allencloud
Lily Guo
Cezar Sa Espinola
Ce Gao
Sebastiaan van Stijn
Erik St. Martin
Aaron Lehmann
Jonh Wendell
Vincent Bernat
Carlos Alexandro Becker
Wenzhi Liang
Paul Kehrer
Vincent Demeester
Denis Gladkikh
Harald Albers
Yong Tang
timfeirg