This may take some time, but start by pointing people at
LABEL instead.
MAINTAINER predates general LABEL and has basically no tooling,
only allows a single item to be added, and is has been
unofficially deprecated for some time, with many images not
including it, but we have never specifically said that it
should be replaced by LABEL as a better more generic metadata
solution.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The indexing of steps in the output of `docker build` starts with `Step 1`.
However, there are several places in the docs that start with `Step 0`.
This fix addresses the issue and changes `Step 0` to `Step 1` (and subsequent steps).
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
When xfs filesystem is being used on top of thin pool, xfs can get ENOSPC
errors from thin pool when thin pool is full. As of now xfs retries the
IO and keeps on retrying and does not give up. This can result in container
application being stuck for a very long time. In fact I have seen instances
of unkillable processes. So that means once thin pool is full and process
gets stuck, container can't be stopped/killed either and only option left
seems to be power recycle of the box.
In another instance, writer did not block but failed after a while. But
when I tried to exit/stop the container, unmounting xfs hanged and only
thing I could do was power cycle the machine.
Now upstream kernel has committed patches where it allows user space to
customize user space behavior in case of errors. One of the knobs is
max_retries, which specifies how many times an IO should be retried
when ENOSPC is encountered.
This patch sets provides a tunable knob (dm.xfs_nospace_max_retries) so
that user can specify value for max_retries and tune xfs behavior. If
one sets this value to 0, xfs will not retry IO when ENOSPC error is
encountered. It will instead give up and shutdown filesystem.
This knob can be useful if one is running into unkillable
processes/containers issue on top of xfs.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
As is raised in 26312, in `docker network ls`, the help output was
mistaken to `volume names`:
```
-q, --quiet Only display volume names
```
This fix changes the help output to:
```
-q, --quiet Only display network IDs
```
This fix also updates the documentation in:
`docs/reference/commandline/network_ls.md`
This fix fixes 26312.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
The `--rm` flag has been part of the `docker create` and
related docs in `docs/reference/commandline/create.md`
already includes the `--rm` flag. However, man page
`man/docker-create.1.md` has not adds the `--rm` flag yet.
This fix adds the description of `--rm` flag to
`man/docker-create.1.md`
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Remove checks that prevent overlay and SELinux from working together.
Fixes are arriving in the 4.9 kernel.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
This fix tries to address the issue raised in 25304 to support
`--group-add` and `--group-rm` in `docker service create`.
This fix adds `--group-add` to `docker service create` and `docker service update`,
adds `--group-rm` to `docker service update`.
This fix updates docs for `docker service create` and `docker service update`:
1. Add `--group-add` to `docker service create` and `docker service update`
2. Add `--group-rm` to `docker service update`
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Since 20848 has been merged and both `docker create` and
`docker run` share the same `runconfig` parser, now both
`docker run` and `docker create` allow to specify the
`--rm` flag. However, docs for `docker create` has not
been udpated yet.
This fix updates docs for `docker create` so that `--rm`
flag has been included.
This fix is related to 20848 and 25577.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>