This adds a direct link to the event chart image
so that the full-resolution image can be "zoomed"
in to.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 86de72fef244b3fe209e5793deb40fb26f5b318e
Component: engine
`Mounts` allows users to specify in a much safer way the volumes they
want to use in the container.
This replaces `Binds` and `Volumes`, which both still exist, but
`Mounts` and `Binds`/`Volumes` are exclussive.
The CLI will continue to use `Binds` and `Volumes` due to concerns with
parsing the volume specs on the client side and cross-platform support
(for now).
The new API follows exactly the services mount API.
Example usage of `Mounts`:
```
$ curl -XPOST localhost:2375/containers/create -d '{
"Image": "alpine:latest",
"HostConfig": {
"Mounts": [{
"Type": "Volume",
"Target": "/foo"
},{
"Type": "bind",
"Source": "/var/run/docker.sock",
"Target": "/var/run/docker.sock",
},{
"Type": "volume",
"Name": "important_data",
"Target": "/var/data",
"ReadOnly": true,
"VolumeOptions": {
"DriverConfig": {
Name: "awesomeStorage",
Options: {"size": "10m"},
Labels: {"some":"label"}
}
}]
}
}'
```
There are currently 2 types of mounts:
- **bind**: Paths on the host that get mounted into the
container. Paths must exist prior to creating the container.
- **volume**: Volumes that persist after the
container is removed.
Not all fields are available in each type, and validation is done to
ensure these fields aren't mixed up between types.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: fc7b904dced4d18d49c8a6c47ae3f415d16d0c43
Component: engine
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>
Upstream-commit: 256dbe4b752ba1fde88e6fad76e3a6b08e4a8816
Component: engine
The "Stream details" sections are currently a part of the Status codes list.
This change moves them out to the same level as other surrounding sections.
Use () for a paramaters
Remove query param from end point heading
Signed-off-by: Matt Hoyle <matt@deployable.co>
Upstream-commit: e0a552504e64192946c86d3bdd517ae7b3af348f
Component: engine
The restriction is no longer necessary given changes at the runc layer
related to mount options of the rootfs. Also cleaned up the docs on
restrictions left for userns enabled mode. Re-enabled tests related to
--read-only when testing a userns-enabled daemon in integration-cli.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 6062ae5742e49ec1a79073c327f3d1343c218a12
Component: engine
More info on endpoint setting, and service discovery on swarm mode overlay network.
Signed-off-by: Richard Mathie <richard.mathie@amey.co.uk>
Upstream-commit: 21a9c64b77bd10969dde7376060d5750c6b65aac
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
This was missing from the docs for 1.12.0.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: fb8b6438f265532ec47e001b2739ed614b47f3a0
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
