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
This version brings in upto-date important bug-fixes from libnetwork
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: a3d22c764cfc3e175cdfb992f3b2314f23540236
Component: engine
Continues 11858 by:
- Making sure the exit code is always zero when we ask for help
- Making sure the exit code isn't zero when we print help on error cases
- Making sure both short and long usage go to the same stream (stdout vs stderr)
- Making sure all docker commands support --help
- Test that all cmds send --help to stdout, exit code 0, show full usage, no blank lines at end
- Test that all cmds (that support it) show short usage on bad arg to stderr, no blank line at end
- Test that all cmds complain about a bad option, no blank line at end
- Test that docker (w/o subcmd) does the same stuff mentioned above properly
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 8324d7918b9c84c5f6508064801534dfd2155c90
Component: engine