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>
Upstream-commit: 6ac8224207a99f7057222fb0b36f4a0bdcc1197c
Component: engine
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>
Upstream-commit: b9e46235fadc6b390e2c04c44b6a865e4ea97cb8
Component: engine
Fix issue where environment variables with embedded equals signs were
being dropped and not passed to the container.
Fixes#26178.
Signed-off-by: Matt Richardson <matt.richardson@octopus.com>
Upstream-commit: bc8eabce252e8363263e9baacdeb1de508029d06
Component: engine
This was missing from the docs for 1.12.0.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: fb8b6438f265532ec47e001b2739ed614b47f3a0
Component: engine
This fix tries to address the issue raised in 26220 where
disconnecting a container from network does not work if
the network id (instead of network name) has been specified.
The issue was that internally when trying to disconnecting
a contaienr fromt the network, the originally passed network
name or id has been used.
This fix uses the resolved network name (e.g., `bridge`).
An integration test has been added to cover the changes.
This fix fixes 26220.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 83d79f13aa2e94085e83e0f5bc5d51305dd2c192
Component: engine
This fix tries to address the issue in 26173 where `docker import -c`
with quoted flags returns an error.
The issue was that in `api/client/image/import.go` the flag
`--change/-c` was handled by `StringSliceVarP` which does not handle
the quote well.
The similiar issue was enountered for 23309 (`docker commit`).
This fix takes the same approach as 23309 where `StringSliceVarP`
was replaced with `VarP` and `opts.ListOpts`.
An integration test has been added to cover the changes.
This fix fixes 26173.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: a79a27412d721a042ae96b411ab1b5b926a7d28a
Component: engine
It makes systemd integration less intrusive, notably needed for
docker machine (cf. https://github.com/docker/machine/pull/3605).
The default storage driver would now be devicemapper, until the
deb package is updated.
Signed-off-by: Bilal Amarni <bilal.amarni@gmail.com>
Upstream-commit: de078211b30e13825b596ff4b2798e0fb780551a
Component: engine
Now that gccgo isn't supported, change the ppc64le dockerfile base image
from a debian:jessie based + gccgo image to a debian:jessie + golang image.
Also includes a go path change to be more consistent across Dockerfiles.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: a243f35cf8906dc6d541dc3dd779a0a2c90cfa12
Component: engine
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>
Upstream-commit: 4f0017b9ad7dfa2e9dcdee69d000b98595893e60
Component: engine
