Set HTTP upgrade headers when hijacking connection

Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>
Set HTTP upgrade header only when requested by client

Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>
Add test to enforce volume build content

This tests ensures that the content from a dir within a build is carried
over even if VOLUME for that dir is specified in the Dockerfile.  This
test ensures this long standing functionality.

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Fix volumes-from/bind-mounts passed in on start

Fixes #9628
Slightly reverts #8683, HostConfig on start is _not_ deprecated.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Bump to version 1.4.1

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Merge pull request #9679 from crosbymichael/bump_v1.4.1

Bump to version v1.4.1
Change version to 1.4.1-dev
upstart: Don't emit "started" event until docker.sock is available

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>
Merge pull request #9695 from crosbymichael/merge_release_v1.4.1

Merge release v1.4.1
Merge pull request #9287 from drothlis/fix-upstart-race-condition

upstart: Don't emit "started" event until docker.sock is available
Update connection hijacking documentation with HTTP Upgrade Headers

Signed-off-by: Jean-Tiare Le Bigot <jt@yadutaf.fr>
Remove DCO small patch exception

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>
Remove small patch exception checking in hack/make/validate-dco

Signed-off-by: Andrew Page <admwiggin@gmail.com>
Give maintainers the power to add contributor's DCO to a commit message, or to use their own if its a trvial change

Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>
Merge pull request #9652 from yadutaf/master

Set HTTP upgrade headers when hijacking connection
Chnage LookupRemoteImage to return error
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>
Merge pull request #9083 from SvenDowideit/pr_out_remove_small_patch_exception_checking_in_hack_make_validate_dco

Remove small patch exception checking in hack/make/validate-dco
Merge pull request #9701 from crosbymichael/registry-lookup-image

Change LookupRemoteImage to return error
Additions for 1.4.1 release

Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Merge pull request #9703 from fredlf/1.4.1-docs-update

Additions for 1.4.1 release