This fixes the "deprecated" comment to have the correct format to be picked
up by editors, and adds `omitempty` labels for KernelMemory and KernelMemoryTCP.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Omit `KernelMemory` and `KernelMemoryTCP` fields in `/info` response if they're
not supported, or when using API v1.42 or up.
- Re-enable detection of `KernelMemory` (as it's still needed for older API versions)
- Remove warning about kernel memory TCP in daemon logs (a warning is still returned
by the `/info` endpoint, but we can consider removing that).
- Prevent incorrect "Minimum kernel memory limit allowed" error if the value was
reset because it's not supported by the host.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- remove KernelMemory option from `v1.42` api docs
- remove KernelMemory warning on `/info`
- update changes for `v1.42`
- remove `KernelMemory` field from endpoints docs
Signed-off-by: aiordache <anca.iordache@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This field was used when Windows did not yet support regular images, and required
the base-image to pre-exist on the Windows machine (as those layers were not yet
allowed to be distributed).
Commit f342b27145 (docker 1.13.0, API v1.25) removed
usage of the field. The field was not documented in the API, but because it was not
removed from the Golang structs in the API, ended up in the API documentation when
we switched to using Swagger instead of plain MarkDown for the API docs.
Given that the field was never set in any of these API versions, and had an "omitempty",
it was never actually returned in a response, so should be fine to remove from these
API docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- rename definition in swagger from `Image` to `ImageInspect` to match the go type
- improve (or add) documentation for various fields
- move example values in-line in the "definitions" section
- remove the `required` fields from `ImageInspect`, as the type is only used as
response type (not to make requests).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The endpoint was silently ignoring invalid values for the "condition" parameter.
This patch now returns a 400 status if an unknown, non-empty "condition" is passed.
With this patch:
curl --unix-socket /var/run/docker.sock -XPOST 'http://localhost/v1.41/containers/foo/wait?condition=foobar'
{"message":"invalid condition: \"foobar\""}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch updates the swagger, and:
- adds an enum definition to document valid values (instead of describing them)
- updates the description to mention both "omitted" and "empty" values (although
the former is already implicitly covered by the field being "optional" and
having a default value).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 0380fbff37 added the ability to pass a
--platform flag on `docker import` when importing an archive. The intent
of that commit was to allow importing a Linux rootfs on a Windows daemon
(as part of the experimental LCOW feature).
A later commit (337ba71fc1) changed some
of this code to take both OS and Architecture into account (for `docker build`
and `docker pull`), but did not yet update the `docker image import`.
This patch updates the import endpoitn to allow passing both OS and
Architecture. Note that currently only matching OSes are accepted,
and an error will be produced when (e.g.) specifying `linux` on Windows
and vice-versa.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 3b5fac462d / docker 1.10 removed support
for the LXC runtime, and removed the corresponding fields from the API (v1.22).
This patch removes the `HostConfig.LxcConf` field from the API documentation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This takes the changes from 1a933e113d and
834272f978, and applies them to older API
versions in the docs directory (which are used for the actual documentation).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 135cec5d4d added support for
calling the /system/df endpoint concurrently.
This patch adds a note about this enhancement to the API changes.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Let clients choose object types to compute disk usage of.
Signed-off-by: Roman Volosatovs <roman.volosatovs@docker.com>
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
The reasoning for this change is to be able to query image shared size without having to rely on the more heavyweight `/system/df` endpoint.
Signed-off-by: Roman Volosatovs <roman.volosatovs@docker.com>
- Using "/go/" redirects for some topics, which allows us to
redirect to new locations if topics are moved around in the
documentation.
- Updated some old URLs to their new location.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While the field in the Go struct is named `NanoCPUs`, it has a JSON label to
use `NanoCpus`, which was added in the original pull request (not clear what
the reason was); 846baf1fd3
Some notes:
- Golang processes field names case-insensitive, so when *using* the API,
both cases should work, but when inspecting a container, the field is
returned as `NanoCpus`.
- This only affects Containers.Resources. The `Limits` and `Reservation`
for SwarmKit services and SwarmKit "nodes" do not override the name
for JSON, so have the canonical (`NanoCPUs`) casing.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Current description of the "v" option doesn't explain what happens to
the volumes that are still in use by other containers. Turns out that
the only volumes that are removed are unnamed ones[1].
Perhaps a good way of clarifying this behavior would be adapting the
description from "docker rm --help".
As for the docs/api/v1.*.yaml changes — they seem to be applicable,
since the origin of this behavior dates way back to the 2016 or v1.11[2].
[1]: a24a71c50f/daemon/mounts.go (L34-L38)
[2]: dd7d1c8a02
Signed-off-by: Nikolay Edigaryev <edigaryev@gmail.com>
Add Ulimits field to the ContainerSpec API type and wire it to Swarmkit.
This is related to #40639.
Signed-off-by: Albin Kerouanton <albin@akerouanton.name>
This patch adds a new "prune" event type to indicate that pruning of a resource
type completed.
This event-type can be used on systems that want to perform actions after
resources have been cleaned up. For example, Docker Desktop performs an fstrim
after resources are deleted (https://github.com/linuxkit/linuxkit/tree/v0.7/pkg/trim-after-delete).
While the current (remove, destroy) events can provide information on _most_
resources, there is currently no event triggered after the BuildKit build-cache
is cleaned.
Prune events have a `reclaimed` attribute, indicating the amount of space that
was reclaimed (in bytes). The attribute can be used, for example, to use as a
threshold for performing fstrim actions. Reclaimed space for `network` events
will always be 0, but the field is added to be consistent with prune events for
other resources.
To test this patch:
Create some resources:
for i in foo bar baz; do \
docker network create network_$i \
&& docker volume create volume_$i \
&& docker run -d --name container_$i -v volume_$i:/volume busybox sh -c 'truncate -s 5M somefile; truncate -s 5M /volume/file' \
&& docker tag busybox:latest image_$i; \
done;
docker pull alpine
docker pull nginx:alpine
echo -e "FROM busybox\nRUN truncate -s 50M bigfile" | DOCKER_BUILDKIT=1 docker build -
Start listening for "prune" events in another shell:
docker events --filter event=prune
Prune containers, networks, volumes, and build-cache:
docker system prune -af --volumes
See the events that are returned:
docker events --filter event=prune
2020-07-25T12:12:09.268491000Z container prune (reclaimed=15728640)
2020-07-25T12:12:09.447890400Z network prune (reclaimed=0)
2020-07-25T12:12:09.452323000Z volume prune (reclaimed=15728640)
2020-07-25T12:12:09.517236200Z image prune (reclaimed=21568540)
2020-07-25T12:12:09.566662600Z builder prune (reclaimed=52428841)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
After dicussing with maintainers, it was decided putting the burden of
providing the full cap list on the client is not a good design.
Instead we decided to follow along with the container API and use cap
add/drop.
This brings in the changes already merged into swarmkit.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Kernel memory limit is not supported on cgroup v2.
Even on cgroup v1, kernel memory limit (`kmem.limit_in_bytes`) has been deprecated since kernel 5.4.
0158115f70
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The initial implementation followed the Swarm API, where
PidsLimit is located in ContainerSpec. This is not the
desired place for this property, so moving the field to
TaskTemplate.Resources in our API.
A similar change should be made in the SwarmKit API (likely
keeping the old field for backward compatibility, because
it was merged some releases back)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Support for PidsLimit was added to SwarmKit in docker/swarmkit/pull/2415,
but never exposed through the Docker remove API.
This patch exposes the feature in the repote API.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The pages that were linked to have moved, so changing the
links to point to docs.docker.com instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adding separate documents for older API versions, so that these don't have to
be collected from each tag/release branch. For each version of the API, I picked
the highest release that uses the API (to make sure to include possible fixes
in the swagger);
git mv api/swagger.yaml api/swagger-current.yaml
git checkout v18.05.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.37.yaml
git checkout v18.02.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.36.yaml
git checkout v18.01.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.35.yaml
git checkout v17.11.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.34.yaml
git checkout v17.10.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.33.yaml
git checkout v17.09.1-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.32.yaml
git checkout v17.07.0-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.31.yaml
git checkout v17.06.2-ce -- api/swagger.yaml
git mv api/swagger.yaml docs/api/v1.30.yaml
git mv api/swagger-current.yaml api/swagger.yaml
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Metrics collectors generally don't need the daemon to prime the stats
with something to compare since they already have something to compare
with.
Before this change, the API does 2 collection cycles (which takes
roughly 2s) in order to provide comparison for CPU usage over 1s. This
was primarily added so that `docker stats --no-stream` had something to
compare against.
Really the CLI should have just made a 2nd call and done the comparison
itself rather than forcing it on all API consumers.
That ship has long sailed, though.
With this change, clients can set an option to just pull a single stat,
which is *at least* a full second faster:
Old:
```
time curl --unix-socket
/go/src/github.com/docker/docker/bundles/test-integration-shell/docker.sock
http://./containers/test/stats?stream=false\&one-shot=false > /dev/null
2>&1
real0m1.864s
user0m0.005s
sys0m0.007s
time curl --unix-socket
/go/src/github.com/docker/docker/bundles/test-integration-shell/docker.sock
http://./containers/test/stats?stream=false\&one-shot=false > /dev/null
2>&1
real0m1.173s
user0m0.010s
sys0m0.006s
```
New:
```
time curl --unix-socket
/go/src/github.com/docker/docker/bundles/test-integration-shell/docker.sock
http://./containers/test/stats?stream=false\&one-shot=true > /dev/null
2>&1
real0m0.680s
user0m0.008s
sys0m0.004s
time curl --unix-socket
/go/src/github.com/docker/docker/bundles/test-integration-shell/docker.sock
http://./containers/test/stats?stream=false\&one-shot=true > /dev/null
2>&1
real0m0.156s
user0m0.007s
sys0m0.007s
```
This fixes issues with downstreams ability to use the stats API to
collect metrics.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This adds a new `fluentd-request-ack` logging option for the Fluentd
logging driver. If enabled, the server will respond with an acknowledgement.
This option improves the reliability of the message transmission. This
change is not versioned, and affects all API versions.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
