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
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
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>
Upstream-commit: eac27ad46d7df4f11a28b84130ff484224f8b63d
Component: engine
Fixed two misspellings of the word "beginning".
Signed-off-by: JacobEdelman <edelman.jd@gmail.com>
Upstream-commit: 97f07bb61ccf6e5a3a0fcc72894d5f37310d0109
Component: engine
_docker_run and _docker_create had only one differing line.
This refactoring features:
- direct completion for both commands to the same function
- factor out the common arguments, sort & format them nicely
- compute the argument for _docker_pos_first_nonflag.
Signed-off-by: Harald Albers <github@albersweb.de>
Upstream-commit: 46b104bd3977c4777b0d99ba6c190f37ae780245
Component: engine
When we use the engine/env object we can run into a situation where
a string is passed in as the value but later on when we json serialize
the name/value pairs, because the string is made up of just numbers
it appears as an integer and not a string - meaning no quotes. This
can cause parsing issues for clients.
I tried to find all spots where we call env.Set() and the type of the
name being set might end up having a value that could look like an int
(like author). In those cases I switched it to use env.SetJson() instead
because that will wrap it in quotes.
One interesting thing to note about the testcase that I modified is that
the escaped quotes should have been there all along and we were incorrectly
letting it thru. If you look at the metadata stored for that resource you
can see the quotes were escaped and we lost them during the serialization
steps because of the env.Set() stuff. The use of env is probably not the
best way to do all of this.
Closes: #9602
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: d942c59b696d16def85f6b65ae65c176f66a5562
Component: engine
Because this is already tested by TestRunExitOnStdinClose in
integration-cli/docker_cli_run_test.go
Signed-off-by: Alexandr Morozov <lk4d4@docker.com>
Upstream-commit: 4d7359f63db200298f9d07f6434a7a4b16c25c88
Component: engine
This test tests nothing because of error in cmd, where "echo 'should
fail'" passed as binary. Also this test directly contradicts
documentation and current daemon behavior.
Fixes#7826
Signed-off-by: Alexandr Morozov <lk4d4@docker.com>
Upstream-commit: 70a2b64ef2e31aef84c39b979686e9194aee22a6
Component: engine
Fixed a missing link and a few small formatting issues. Also deleted 1.3 notes as originally intended.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Upstream-commit: afc262cc3ab68129104e3d799f8a2694f61aa68f
Component: engine
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>
Upstream-commit: 4856ec075422a7926b62762749a7fbcc869efa99
Component: engine
