For now CLI `docker stats` will not block even if the container was
not running is because there is a 2s timeout setting when waiting for
the response.
I think why we hang there waiting for the container to run is because we
want to get the stats of container immediately when it starts running.
But it will block when use the API directly, for example
- curl
- Google Chrome plugin, Postman
- Firefox plugin, RESTClient
This patch keeps the feature that getting info immediately when container
starts running and in the meantime, it will not block when using the API
directrly.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Upstream-commit: d9bf8163ad8579cf2ab9f55925f9ea5037e5b525
Component: engine
Update and migrate existing tests to the `DockerHubPullSuite`. Most
tests were preserved, but refactored and made more exhaustive. One test
was deliberately removed (`TestPullVerified`) as it is unreliable and
that the feature was obsoleted by content trust.
Move all trust related tests to `docker_cli_pull_trusted_test.go`.
Move tests depending on a local registry to `docker_cli_pull_local_test.go`.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: f324f4851f28edfd8dab82cd624a4ec1f01cd207
Component: engine
Add a `checker` package that adds some utility Checker implementation,
the first one being `checker.Contains`, as well as brining all go-check
provided Checker implementations in scope as a commodity.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: c87cbd3862336fb01addff5d753ff7c8e0d50879
Component: engine
we changed the naming scheme of the release branch
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
Upstream-commit: e38a9ecef6849304b6d961b24af16fbd1f4912d6
Component: engine
Regarding the outdated error check, there's no `docker.PortMapping`
struct anymore and this is linked to something really old #1334
Signed-off-by: Antonio Murdaca <runcom@linux.com>
Upstream-commit: 137c12f19a6838eeebfd45c459b883bb69f53d36
Component: engine
Introduce the `DockerHubPullSuite` that interacts with its own dedicated
daemon, thus allowing to start from a clean environment and finely test
against the impact of isolated push and pull operations.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 9e4addde76f4aea4613f09215084812b6a357521
Component: engine
- Ground-work for integrating with user namespace support
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: 56fdb05258d1ab2153fec268ed22cf9d1227c356
Component: engine
When using a named volume without --volume-driver, the driver was
hardcoded to "local".
Even when the volume was already created by some other driver (and
visible in `docker volume ls`), the container would store in it's own
config that it was the `local` driver.
The external driver would work perfecly fine until the daemon is
restarted, at which point the `local` driver was assumed because that is
as it was set in the container config.
Set the bind driver to the driver returned by createVolume.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 39be36658d559d0fe28c902ad0f45287868c7ebb
Component: engine
Main changes in this vendoring are to allow user name space integration in docker.
And it includes major fix for network namespace handling
Signed-off-by: Alessandro Boch <aboch@docker.com>
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: 414dfbf681d956c11c83d9b7598962a1294f2c5d
Component: engine