Handle unresolvable domain names in isSecure to allow HTTP proxies to work as expected
Upstream-commit: b88d9699ff7577e7d7a42ba4477cbfca45a953da
Component: engine
- move docker/docker-py clone to the Dockerfile
- put "integration test daemon startup" code in a separate file for both scripts to source
- add new test-docker-py Makefile target
- include "python-websocket" package in Dockerfile for running the tests
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 100267de81985bbf3b976bfde850def89487dc11
Component: engine
Clarify Mac OS X experience. Signed-off by: Mary Anthony (moxieandmore@g...
Upstream-commit: 3e3749fe4b72c6fe9afd44c35c79c804b3ef1678
Component: engine
to allow HTTP proxies to work as expected.
Fixes#9708
Signed-off-by: Tibor Vass <teabee89@gmail.com>
Upstream-commit: ff4bfcc0e9f171a95dac5cc2650faacf73943057
Component: engine
There has been a lot of discussion (issues 4242 and 5262) about making
`FROM scratch` either a special case or making `FROM` optional, implying
starting from an empty file system.
This patch makes the build command `FROM scratch` special cased from now on
and if used does not pull/set the the initial layer of the build to the ancient
image ID (511136ea..) but instead marks the build as having no base image. The
next command in the dockerfile will create an image with a parent image ID of "".
This means every image ever can now use one fewer layer!
This also makes the image name `scratch` a reserved name by the TagStore. You
will not be able to tag an image with this name from now on. If any users
currently have an image tagged as `scratch`, they will still be able to use that
image, but will not be able to tag a new image with that name.
Goodbye '511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158',
it was nice knowing you.
Fixes#4242
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 8936789919c5c8004f346f44a3452d1521818b60
Component: engine
To avoid an expensive call to archive.ChangesDirs() which walks two directory
trees and compares every entry, archive.ApplyLayer() has been extended to
also return the size of the layer changes.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 35a22c9e12c05e2a0a205964702ced78ea39d7a1
Component: engine
This clones and run the integration tests for docker-py master as part
of the integration tests created on master. docker-py hits the api
directly and should be a good way to identify regressions in the api.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 5d6eca6642c5749099513f1f66bb44e004aa0938
Component: engine
This patch fixes the indenting.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Upstream-commit: bc1507dfce956846ba1515ccbfcd202c06aa995b
Component: engine
This commit is patch for following comment
// TODO: This method should return the errors instead of masking them and returning false
Signed-off-by: Daehyeok Mun <daehyeok@gmail.com>
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 8123c1e9fef0eb0d6b4e89dce4089276b751906c
Component: engine
As we move forward on automating our pull request review process and
tooling these exceptions hurt more than they help. For consistency we
should not allow small patch exceptions for anything. The source of
truth going forward for DCO and builds are the official drone status on
each pull request.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: af72f2128e7c4ebd12a9fef7e7381ef42a52ed0c
Component: engine
Fixes#6647: Other upstart jobs that depend on docker by specifying
"start on started docker" would often start before the docker daemon was
ready, so they'd fail with "Cannot connect to the Docker daemon" or
"dial unix /var/run/docker.sock: no such file or directory".
This is because "docker -d" doesn't daemonize, it runs in the
foreground, so upstart can't know when the daemon is ready to receive
incoming connections. (Traditionally, a daemon will create all necessary
sockets and then fork to signal that it's ready; according to @tianon
this "isn't possible in Go"[1]. See also [2].)
Presumably this isn't a problem with systemd init with its socket
activation. The SysV init scripts may or may not suffer from this
problem but I have no motivation to fix them.
This commit adds a "post-start" stanza to the upstart configuration
that waits for the socket to be available. Upstart won't emit the
"started" event until the "post-start" script completes.[3]
Note that the system administrator might have specified a different path
for the socket, or a tcp socket instead, by customising
/etc/default/docker. In that case we don't try to figure out what the
new socket is, but at least we don't wait in vain for
/var/run/docker.sock to appear.
If the main script (`docker -d`) fails to start, the `initctl status
$UPSTART_JOB | grep -q "stop/"` line ensures that we don't loop forever.
I stole this idea from Steve Langasek.[4]
If for some reason we *still* end up in an infinite loop --I guess
`docker -d` must have hung-- then at least we'll be able to see the
"Waiting for /var/run/docker.sock" debug output in
/var/log/upstart/docker.log.
I considered using inotifywait instead of sleep, but it isn't worth
the complexity & the extra dependency.
[1] https://github.com/docker/docker/issues/6647#issuecomment-47001613
[2] https://code.google.com/p/go/issues/detail?id=227
[3] http://upstart.ubuntu.com/cookbook/#post-start
[4] https://lists.ubuntu.com/archives/upstart-devel/2013-April/002492.html
Signed-off-by: David Röthlisberger <david@rothlis.net>
Upstream-commit: f42c0a53a38a2a141bec8768d0836a3726de4a83
Component: engine
