When plugins have a positive refcount, they were not allowed to be
removed. However, plugins could still be disabled when volumes
referenced it and containers using them were running.
This change fixes that by enforcing plugin refcount during disable.
A "force" disable option is also added to ignore reference refcounting.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 8cb2229cd18c53bdbf36301f26db565a50027d6a
Component: engine
This will help when extracting suites in their own package.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 930a9869f6cb13bcdd44def2d445cb4505f2dd50
Component: engine
Signed-off-by: Jie Luo <luo612@zju.edu.cn>
typo
Signed-off-by: Jie Luo <luo612@zju.edu.cn>
fix some typos
Signed-off-by: Jie Luo <luo612@zju.edu.cn>
Upstream-commit: ea2dd4b5d0b41552d047814d9e39ddaa3662ab41
Component: engine
This fix is a follow up for comment:
https://github.com/docker/docker/pull/29186/files#r91277345
While #29186 addresses the issue of `docker inspect <unknown object>`
on Windows, it actually makes `docker plugin inspect <unknown object>`
out `object not found` on Windows as well. This is actually misleading
as plugin is not supported on Windows.
This fix reverted the change in #29186 while at the same time,
checks `not supported` in `docker inspect <unknown object>` so that
- `docker plugin inspect <unknown object>` returns `not supported` on Windows
- `docker inspect <unknown object>` returns `not found` on Windows
This fix is related to #29186 and #29185.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 0b3c10ac4ddfe3655bac080440a8553269f2307f
Component: engine
Sets a kernel requirement for for `TestGraphdriverPlugin` since the
graphdriver being used is overlay2.. and also makes sure to skip the
kernel check in the actual graphdriver since we may be able to detect
kernels with backported support for overlay2 style mounts a bit more
freely in the test code.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e4ebc92edc85d2f46cf41c4ad9514ba0fbafed06
Component: engine
The `docker logs` command performed a
client-side check if the container's
logging driver was supported.
Now that we allow the client to connect
to both "older" and "newer" daemon versions,
this check is best done daemon-side.
This patch remove the check on the client
side, and leaves validation to the daemon,
which should be the source of truth.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 05dc9846e1266e6a3629c26851acb633a380dd17
Component: engine
… and given where it was used, it should be quicker to create an empty
folder instead of passing potentially a big context with unrelated file.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 3dd25b97902e064f43d56632d3a72768e36eecc5
Component: engine
check to see if the node is part of a swarm, and if so, if it is unlocked first.
If neither of these are true, abort the command.
Signed-off-by: Ying Li <ying.li@docker.com>
Upstream-commit: a6a0880a22e2b135d8a20a46b9ba34c7a9cf2f10
Component: engine
Previously, it was comparing against the driver name passed in by the
caller. This could lead to subtle issues when using plugins, like
"plugin" vs. "plugin:latest".
Also, remove "conflict:" prefix to improve the error message.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 53d447c5d5c85d5595d5170411189c88a135a789
Component: engine
Ensures all known volumes (known b/c they are persisted to disk) have
their volume drivers refcounted properly.
In testing this, I found an issue with `--live-restore` (required since
currently the provided volume plugin doesn't keep state on restart)
where restorted plugins did not have a plugin client loaded causing a
panic when trying to use the plugin.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 6ef1060cd0acb847e06db890abb335faa837a9e2
Component: engine
Also enables `PropagatedMount` for graphdrivers.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 500210475f6d841b2eacb42fb495e90108db2733
Component: engine
… to flood a little bit less the integration cli output. Now use any
testing framework that has a LogF function.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: cf2ea7613899477caf69145e2bd15aa6e731d5c4
Component: engine
This fix tries to address the issue raised in 29342 where
`docker exec -u` after docker daemon restart returns an error:
```
unable to find user test: no matching entries in passwd file
```
The reason was that `container.BaseFS` is not present after restart.
This fix adds the `daemon.Mount` during the restore to bring up the
`container.BaseFS`.
An integration test has been added to cover the changes.
This fix fixes 29342.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7feb2a17e4b9d1a5305a8a44004e916b79cbdd97
Component: engine
Fixes an issue when starting the daemon with live-restore
where previously it was not set, plugins are not running.
Fixes an issue when starting the daemon with live-restore, the plugin
client (for interacting with the plugins HTTP interface) is not set,
causing a panic when the plugin is called.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: cb6633175c0de0a7ae155c4d378cd2379681554b
Component: engine
This fix tries to address the issue raised in 28581 and 28927
where it is not possible to create a secret from a file (only
through STDIN).
This fix add a flag `--file` to `docker secret create` so that
it is possible to create a secret from a file with:
```
docker secret create --file secret.in secret.name
```
or
```
echo TEST | docker secret create --file - secret.name
```
Related docs has been updated.
An integration test has been added to cover the changes.
This fix fixes 28581.
This fix is related to 28927.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: c6f0b7f448fac4d037d00f944a7908c60c04dff2
Component: engine
This fix tries to address the issue raised in 24352. Previously,
when `docker swarm update` has no flags, the output is
```
Swarm updated.
```
even though nothing was updated. This could be misleading for
users.
This fix tries to address the issue by adding a `PreRunE` function
in the command so that in case no flag is provided (`cmd.Flags().NFlag() == 0`),
the usage will be outputed instead.
An integration has been added to cover the changes.
This fix fixes 24352.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 5aa5a1cb008963ee6a99011b8f7cd1f489e2bc6a
Component: engine
The success of the win2lin CI before was really "by chance" on the
DockerDaemonSuite : the DockerDaemonSuite was panicking when starting
the daemon on the first non-skipped test.The suite panicked but as
the error returned from `StartWithBusybox` was nil, the test kept
going and was OK because the client had all the correct environment
variables set up to discuss with the remote daemon.
Then, as the suite panicked, no more test attached on the
DockerDaemonSuite ran (that's why on win2lin, `DockerDaemonSuite` was
only composed by 5 tests !). The really bad thing is, we didn't get
any report of the panic on the suite (go-check hiding something
somewhere).
As DockerDaemonSuite needs to run test on the same host as it's
running, this adds a `SameHostDaemon` requirement to the Suite.
This changes also make sure `TestRestartContainerWithRestartPolicy`
does left weirdies behind it.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: e857785df4b53df551ad25d132bc0274923f2e53
Component: engine
