As far as I see, it's a dead code.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Upstream-commit: a34cb321865c16ac42a12fe32fa3c8c4a5ffd263
Component: engine
Which is already done in writeJSON.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: 94d604357ff9cf7a5fcc4d98ffe58f804adf0ae6
Component: engine
UnmountVolumes used to also unmount 'specialMounts' but it no longer does after
a recent refactor of volumes. This patch corrects this behavior to include
unmounting of `networkMounts` which replaces `specialMounts` (now dead code).
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 04f99a6ca8232e43169b9a0706e435c551c798a3
Component: engine
Tibor's comment
Updating with the new plugins
Entering comments from Seb
Signed-off-by: Mary Anthony <mary@docker.com>
Upstream-commit: 1ba1a0550ff3fa98397cd93195cc33b8c2f6473a
Component: engine
This is not necessary and it's a regression from the old behavior.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: f78dce152c3c67bf262648028ff7932ca461b6fd
Component: engine
Strip authconfig from session to keep credentials from being sent to the mirror.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Upstream-commit: c19962ade10619e5edd8057249566c494d4719bb
Component: engine
The v2 registry will act as a pull-through cache, and needs to be
handled differently by the client to the v1 registry mirror.
See docker/distribution#459 for details
Configuration
Only one v2 registry can be configured as a mirror. Acceptable configurations
in this chanage are: 0...n v1 mirrors or 1 v2 mirror. A mixture of v1 and v2
mirrors is considered an error.
Pull
If a v2 mirror is configured, all pulls are redirected to that mirror. The
mirror will serve the content locally or attempt a pull from the upstream mirror,
cache it locally, and then serve to the client.
Push
If an image is tagged to a mirror, it will be pushed to the mirror and be
stored locally there. Otherwise, images are pushed to the hub. This is
unchanged behavior.
Signed-off-by: Richard Scothern <richard.scothern@gmail.com>
Upstream-commit: 13deed380127d4a0e7982bb0d4f6529d0962116b
Component: engine
Having the line break in the middle of a code span caused the line break to appear on the web site version, even though it doesn't appear in the preview.
The other two changes are just small grammar improvements.
Signed-off-by: don <donkirkby@gmail.com>
Upstream-commit: 5051aee555428f5501de2b8fa24000de093220f5
Component: engine
I'm fairly consistently seeing an error in
DockerSuite.TestContainerApiRestartNotimeoutParam:
docker_api_containers_test.go:969:
c.Assert(status, check.Equals, http.StatusNoContent)
... obtained int = 500
... expected int = 204
And in the daemon logs I see:
INFO[0003] Container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971 failed to exit within 0 seconds of SIGTERM - using the force
ERRO[0003] Handler for POST /containers/{name:.*}/restart returned error: Cannot restart container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971: [2] Container does not exist: container destroyed
ERRO[0003] HTTP Error err=Cannot restart container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971: [2] Container does not exist: container destroyed
statusCode=500
Note the "container destroyed" error message. This is being generatd by
the libcontainer code and bubbled up in container.Kill() as a result of the
call to `container.killPossiblyDeadProcess(9)` on line 439.
See the comment in the code, but what I think is going on is that because we
don't have any timeout on the Stop() call we immediate try to force things to
stop. And by the time we get into libcontainer code the process just finished
stopping due to the initial signal, so this secondary sig-9 fails due to the
container no longer running (ie. its 'destroyed').
Since we can't look for "container destroyed" to just ignore the error, because
some other driver might have different text, I opted to just ignore the error
and keep going - with the assumption that if it couldnt send a sig-9 to the
process then it MUST be because its already dead and not something else.
To reproduce this I just run:
curl -v -X POST http://127.0.0.1:2375/v1.19/containers/8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971/restart
a few times and then it fails with the HTTP 500.
Would like to hear some other ideas on to handle this since I'm not
thrilled with the proposed solution.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 29bdcaf3cfe0f4bfeed9f7f59ca8f6ad2f41dfd9
Component: engine
It's a given that lines of example output might be truncated or come
from a contrived environment.
Signed-off-by: Lloyd Dewolf <foolswisdom@gmail.com>
Upstream-commit: ca23ac37efe4b8785751f95d5c09c94811a43ed3
Component: engine
* Don't AllocateNetwork when network is disabled
* Don't createNetwork in execdriver when network is disabled
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 3cb14df68c1a59981907fec3bccab80a1d0dda59
Component: engine
Hu Keping
Qiang Huang
Alexey Guskov
Brian Goff
moxiegirl
Josh Hawn
Arnaud Porterie
Tibor Vass
John Howard
Alexander Morozov
David Calavera
Jessica Frazelle
Tianon Gravi
Derek McGowan
Richard
Sebastiaan van Stijn
Antonio Murdaca
Darren Shepherd
James Turnbull
Ed Costello
Nate Jones
Don Kirkby
Jan-Jaap Driessen
Doug Davis
Zhang Wei
Lloyd Dewolf
Alexander Morozov