While restoring plugins during daemon restart, some plugins can fail to
respond to net.Dial. These plugins should be explicitly set to disabled,
else they will retain their original state of enabled, which is
incorrect.
Tested with a plugin that fails to restart and observed that the state
was set to disabled.
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Upstream-commit: bbbf64f7128c3784f500cd15a994f20ab5d80920
Component: engine
[compose/interpolation] Make sure we error out instead of panic during interpolation
Upstream-commit: 8d2a82853c3401bdffbcc91b12399ef6589d26d0
Component: engine
This fix tries to address the request in 31324 by adding
`--filter scope=swarm|local` for `docker network ls`.
As `docker network ls` has a `SCOPE` column by default,
it is natural to add the support of `--filter scope=swarm|local`.
This fix adds the `scope=swarm|local` support for
`docker network ls --filter`.
Related docs has been updated.
Additional unit test cases have been added.
This fix fixes 31324.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 704ea8f6b4ad6f43c348affe357994d440aaf3de
Component: engine
Use type assertion to error out if the type isn't the right one
instead of panic as before this change.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: c165a8bfa1419724eb504f3cb7fdf3ca1b97483b
Component: engine
Notary switched to vendor a while ago, so make that change here. Change
is consistent with all other dockerfiles.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: 28b99648aea000b01eb9634743110900d025238c
Component: engine
When the daemon is configured to run with an authorization-plugin and if
the plugin is disabled, the daemon continues to send API requests to the
plugin and expect it to respond. But the plugin has been disabled. As a
result, all API requests are blocked. Fix this behavior by removing the
disabled plugin from the authz middleware chain.
Tested using riyaz/authz-no-volume-plugin and observed that after
disabling the plugin, API request/response is functional.
Fixes#31836
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Upstream-commit: 38de272bd4dfea945985b7031cd353ac5f6507c5
Component: engine
Embedding DockerVersion in plugin config when the plugin is created,
enables users to do a docker plugin inspect and know which version
the plugin was built on. This is helpful in cases where users are
running a new plugin on older docker releases and confused at
unexpected behavior.
By embedding DockerVersion in the config, we claim that there's no
guarantee that if the plugin config's DockerVersion is greater that
the version of the docker engine the plugin is executed against, the
plugin will work as expected.
For example, lets say:
- in 17.03, a plugin was released as johndoe/foo:v1
- in 17.05, the plugin uses the new ipchost config setting and author
publishes johndoe/foo:v2
In this case, johndoe/foo:v2 was built on 17.05 using ipchost, but is
running on docker-engine version 17.03. Since 17.05 > 17.03, there's
no guarantee that the plugin will work as expected. Ofcourse, if the
plugin did not use newly added config settings (ipchost in this case)
in 17.05, it would work fine in 17.03.
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Upstream-commit: 342ed107bc6283cfc9b3301142e71f20aae0aaca
Component: engine
It is just an alias type and make the code a little bit more complex
and hard to use from outside `compose` package.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: d3dc27d145a36b3c81fd5999f2c525af95d9596a
Component: engine
