The libzfs-dev package is not needed for the static builds,
and only used for ubuntu packages, so removing from
the Dockerfile.
This resolves an issue where build fails due to the PPA
having changed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 8022c5fdd12ae6dc5aac3c9e59f5524954b55730
Component: engine
URL query encode log details, so that characters like spaces don't make
log parsing ambiguous. Add a helper function to parse these details to a
map, if needed
Add support for details on service logs
Signed-off-by: Drew Erny <drew.erny@docker.com>
Upstream-commit: 68f21418ac1f1acb2874b45878a5938475becf1f
Component: engine
Allows for a plugin type that can be used to scrape metrics.
This is useful because metrics are not neccessarily at a standard
location... `--metrics-addr` must be set, and must currently be a TCP
socket.
Even if metrics are done via a unix socket, there's no guarentee where
the socket may be located on the system, making bind-mounting such a
socket into a container difficult (and racey, failure-prone on daemon
restart).
Metrics plugins side-step this issue by always listening on a unix
socket and then bind-mounting that into a known path in the plugin
container.
Note there has been similar work in the past (and ultimately punted at
the time) for consistent access to the Docker API from within a
container.
Why not add metrics to the Docker API and just provide a plugin with
access to the Docker API? Certainly this can be useful, but gives a lot
of control/access to a plugin that may only need the metrics. We can
look at supporting API plugins separately for this reason.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 0e8e8f0f318656be80e34db9b5e390ffeef3fd0d
Component: engine
in the Docker REST APIs when viewing or updating the swarm spec info, and
also propagate the desired CA key in the Docker REST APIs when updating
swarm spec info only (it is not available for viewing).
Signed-off-by: Ying Li <ying.li@docker.com>
Upstream-commit: 1847bb899a07d3dd324e75a3ed9b3489fcfc302f
Component: engine
In some cases a mount spec would not be properly backported which could
lead to accidental removal of the underlying volume on container remove
(which should never happen with named volumes).
Adds unit tests for this as well. Unfortunately I had to add a daemon
depdency for the backport function due to looking up `VolumesFrom`
specs.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 3cf18596e95c19823387322cb0fc4e324958a341
Component: engine
Fixes a warning that was shown;
Warning: Other properties are defined at the same level as $ref at
"#/paths/~1secrets~1{id}/get/responses/200/schema". They are IGNORED according
to the JsonSchema spec
That resulted in the example not being
rendered in the documentation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f3bcea00cd0de1f874728142babd7b10b379cf15
Component: engine
From Go 1.8 HTTP client redirect behaviour is changed:
When status code is 301, 307 or 308, the client
automatically converts it to a new HTTP request.
This behaviour change manifests in the client in that
before the 301 was not followed and the client did not generate
an error, but now results in an error message:
"Error response from daemon: page not found."
To fix that a new redirect policy is forced by setting
HTTP Client's CheckRedirect.
That policy is to return an error for any 301, 307 or 308
in the response's status code to a non-GET request.
The error message specifies that the daemon could not
process the request and it is probably due to bad
arguments that were provided by the user.
Signed-off-by: Boaz Shuster <ripcurld.github@gmail.com>
Upstream-commit: eb36d6021618f788012c166a533f1b321cda9695
Component: engine
