When connecting with the daemon using a UNIX socket, the HTTP hostname was set, based
on the socket location, which was generating some noise in the test-logs.
Given that the actual hostname is not important (the URL just has to be well-formed),
the hostname/address can be cleaned up to reduce the noise.
This patch strips the path from the `addr`, and keeps `<random-id>.sock` as address.
Before:
daemon.go:329: [d15d31ba75501] error pinging daemon on start: Get http://%2Ftmp%2Fdocker-integration%2Fd15d31ba75501.sock/_ping: dial unix /tmp/docker-integration/d15d31ba75501.sock: connect: no such file or directory
After:
daemon.go:329: [d15d31ba75501] error pinging daemon on start: Get http://d15d31ba75501.sock/_ping: dial unix /tmp/docker-integration/d15d31ba75501.sock: connect: no such file or directory
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 92e6e7dd5f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The test-integration/test=integration-cli directory contains
a directory for each daemon that was created during the integration
tests, which makes it a long list to browse through. In addition,
some tests spin up multiple daemons, and when debugging test-failures,
the daemon-logs often have to be looked at together.
This patch organizes the bundl directory to group daemon storage
locationos per test, making it easier to find information about
all the daemons that were used in a specific test.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 9b5e78888d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds some logs, handles timers better, and sets a request timeout
for the ping request.
I'm not sure the ticker in that loop is what we really want since the
ticker keeps ticking while we are (attempting) to make a request... but
I opted to not change that for now.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 20ea8942b8)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As of Go 1.12, the `testing` package panics if a goroutine logs to a
`testing.T` after the relevant test has completed. This was not
documented as a change at all; see the commit
95d06ab6c982f58b127b14a52c3325acf0bd3926 in the Go repository for the
relevant change.
At any point in the integration tests, tests could panic with the
message "Log in goroutine after TEST_FUNCTION has completed". This was
exacerbated by less direct logging I/O, e.g. running `make test` with
its output piped instead of attached to a TTY.
The most common cause of panics was that there was a race condition
between an exit logging goroutine and the `StopWithError` method:
`StopWithError` could return, causing the calling test method to return,
causing the `testing.T` to be marked as finished, before the goroutine
could log that the test daemon had exited. The fix is simple: capture
the result of `cmd.Wait()`, _then_ log, _then_ send the captured
result over the `Wait` channel. This ensures that the message is
logged before `StopWithError` can return, blocking the test method
so that the target `testing.T` is not marked as finished.
Signed-off-by: Daniel Sweet <danieljsweet@icloud.com>
(cherry picked from commit 7546322e99)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Minor improvement, but makes defining a list of options
a bit cleaner, and more descriptive;
Before:
opts := make([]func(*client.Client) error, 0)
After:
opts := make([]client.Opt, 0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There's no need to try to re-build the test images if they already
exist. This change makes basically no difference to the upstream
integration test-suite running, but for users who want to run the
integration-cli suite on a host machine (such as distributions doing
tests) this change allows images to be pre-loaded such that compilers
aren't needed on the test machine.
However, this does remove the accidental re-compilation of nnp-test, as
well as handling errors far more cleanly (previously if an error
occurred during a test build, further tests won't attempt to rebuild
it).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
As people are using the UUID in `docker info` that was based on the v1 manifest signing key, replace
with a UUID instead.
Remove deprecated `--disable-legacy-registry` option that was scheduled to be removed in 18.03.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Some tests were skipped if the local daemon did not have
experimental features enabled; at the same time, some tests
unconditionally created a new (experimental) daemon, even if
the local daemon already had experimental enabled.
This patch;
- Checks if the "testEnv" is an experimental Linux daemon
- If not, and the daemon is running locally; spin up a new
experimental daemon to be used during the test.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Monitoring systems and load balancers are usually configured to use HEAD
requests for health monitoring. The /_ping endpoint currently does not
support this type of request, which means that those systems have fallback
to GET requests.
This patch adds support for HEAD requests on the /_ping endpoint.
Although optional, this patch also returns `Content-Type` and `Content-Length`
headers in case of a HEAD request; Refering to RFC 7231, section 4.3.2:
The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields
(Section 3.3) MAY be omitted. This method can be used for obtaining
metadata about the selected representation without transferring the
representation data and is often used for testing hypertext links for
validity, accessibility, and recent modification.
A payload within a HEAD request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing
implementations to reject the request.
The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD
response might also have an effect on previously cached responses to
GET; see Section 4.3.5 of [RFC7234].
With this patch applied, either `GET` or `HEAD` requests work; the only
difference is that the body is empty in case of a `HEAD` request;
curl -i --unix-socket /var/run/docker.sock http://localhost/_ping
HTTP/1.1 200 OK
Api-Version: 1.40
Cache-Control: no-cache, no-store, must-revalidate
Docker-Experimental: false
Ostype: linux
Pragma: no-cache
Server: Docker/dev (linux)
Date: Mon, 14 Jan 2019 12:35:16 GMT
Content-Length: 2
Content-Type: text/plain; charset=utf-8
OK
curl --head -i --unix-socket /var/run/docker.sock http://localhost/_ping
HTTP/1.1 200 OK
Api-Version: 1.40
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Docker-Experimental: false
Ostype: linux
Pragma: no-cache
Server: Docker/dev (linux)
Date: Mon, 14 Jan 2019 12:34:15 GMT
The client is also updated to use `HEAD` by default, but fallback to `GET`
if the daemon does not support this method.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
By default, exec uses the environment of the current process, however,
if `exec.Env` is not `nil`, the environment is discarded:
e73f489494/src/os/exec/exec.go (L57-L60)
> If Env is nil, the new process uses the current process's environment.
When adding a new environment variable, prepend the current environment,
to make sure it is not discarded.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit contains changes to configure DataPathPort
option. By default we use 4789 port number. But this commit
will allow user to configure port number during swarm init.
DataPathPort can't be modified after swarm init.
Signed-off-by: selansen <elango.siva@docker.com>
When starting docker daemons for swarm testing, we disable iptables
and use lo for communication (in order to avoid network conflicts).
The problem is, these options are lost on restart, that can lead
to any sorts of network conflicts and thus connectivity issues
between swarm nodes.
Fix this. This does not fix issues with swarm test failures, but
it seems they appear are less often after this one.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
A timer is leaking on every daemon start and stop.
Probably nothing major, but given the amount of
daemon starts/stops during tests, it's better to
be accurate about it.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. Using MNT_FORCE flag does not make sense for nsfs. Using MNT_DETACH
though might help.
2. When -check.vv is added to TESTFLAGS, there are a lot of messages
like this one:
> unmount of /tmp/dxr/d847fd103a4ba/netns failed: invalid argument
and some like
> unmount of /tmp/dxr/dd245af642d94/netns failed: no such file or directory
The first one means directory is not a mount point, the second one
means it's gone. Do ignore both of these.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This feature allows user to specify list of subnets for global
default address pool. User can configure subnet list using
'swarm init' command. Daemon passes the information to swarmkit.
We validate the information in swarmkit, then store it in cluster
object. when IPAM init is called, we pass subnet list to IPAM driver.
Signed-off-by: selansen <elango.siva@docker.com>
Else it is harder to understand where we've failed in StartWithLogFile
We have an errror:
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
[d42ce729d0b06] waiting for daemon to start
docker_cli_userns_test.go:27:
s.d.StartWithBusybox(c, "--userns-remap", "default")
/go/src/github.com/docker/docker/internal/test/daemon/daemon.go:203:
t.Fatalf("Error starting daemon with arguments: %v", args)
... Error: Error starting daemon with arguments: [--userns-remap default]
[d42ce729d0b06] exiting daemon
Likely it is "[..] Daemon exited during startup" case, but these error
message is lost
Also we lose the error returned by waiting daemon so also add it
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
The `deleteAllImages()` cleanup step in the integration suite was printing a
message for each image that was removed.
These messages were not very informative (given that `removeImage()` prints an
error if image removal failed), and made the test output harder to read
(more difficult to see error-conditions when scanning the output).
This patch removes the messages to make the output slightly less noisy.
Before this patch applied:
--- PASS: TestBuildMultiStageOnBuild (7.15s)
main_test.go:32: Removing image sha256:9db3ddbaaadd52804d8a417081f68db41fd4b8f80c85c1b4c4aee2d9b584c074
main_test.go:32: Removing image sha256:7eeb04d90b5e62a99ac6a5b2c10b9ba54b89b176fe2783e41461581c482852b3
main_test.go:32: Removing image sha256:adf42475eefff99b4a611c1a5d8353c4d0a011a7f7b9dc59a75d951cd54fa77f
main_test.go:32: Removing image sha256:c547a770806e0445f5dfc255683ced771a23be6157ba8d0617bb9ab55dcee6d1
main_test.go:32: Removing image sha256:b79659c3e6d34faf2a075f1df1ea2c805833982f112666b25a466177b5d1352d
main_test.go:32: Removing image sha256:29430078cdc927c19c87416cd1fb1ec386f167c5e201ee5dfb1644dcf268a3c2
=== RUN TestBuildUncleanTarFilenames
--- PASS: TestBuildUncleanTarFilenames (2.47s)
main_test.go:32: Removing image sha256:0a6418fb221dc2f25085a1a7e507e01c4a3938cc5c65f1cb85a8c0fb09d6814f
main_test.go:32: Removing image sha256:3d6e4bd0cce01ce5823b40dcb717cd16b3b4b769ff73dd86fa448aac49aa6d7c
main_test.go:32: Removing image sha256:98e3f335e874612668335b3a5f125a1e5cbd0f6c79a7c3f719529b69d0abf2a5
main_test.go:32: Removing image sha256:08919f344b382fd1447da7f3e8ffd2a7125f5f7d191ed7d33242736dbe3c59cf
main_test.go:32: Removing image sha256:d144b3c13838e841ec319a17e1046471d726bb2aa3211e167a6a53f766a2dcdc
main_test.go:32: Removing image sha256:7c768ec742d628020f50c99dc5af32400b78534ca9fc4c01a9f00ec0ab19193a
main_test.go:32: Removing image sha256:4c26c71d142045fbf3448aa1f6363d5a7a803cb438a78a4b20b7c847df03d50a
main_test.go:32: Removing image sha256:08dcd63c964f2dbb17ff2665b6b86993fb14c0d3e169da187ac48f078a560d25
main_test.go:32: Removing image sha256:c1743fab233f36f2d7f83cb13f8c10ff06bdbda8f8a218d25a3796d1bc2f9e84
=== RUN TestBuildMultiStageLayerLeak
--- PASS: TestBuildMultiStageLayerLeak (5.59s)
main_test.go:32: Removing image sha256:5e9974558276c34d7c9aab3fad408d433047b7b15bdae43ab5048adc58a15431
main_test.go:32: Removing image sha256:ac3c613c8c48794237c1e46ac0657ebbb1132910a240086bb2e9df9770fdc017
main_test.go:32: Removing image sha256:a936df268131ad427f7b4b66ce3dbb1e41866d7269a4d383cebcb1c5930d3346
main_test.go:32: Removing image sha256:5e613ea0ce7dbc908b0315c49585ae43ad6c34158e9e0b59a3dc93b00ef0ea41
main_test.go:32: Removing image sha256:e676f4ec41a42823b6d91e05e3290d3827f9175dea6fba5d8b769aa13aa7e082
main_test.go:32: Removing image sha256:93c8daab2703126b23d957d4d6b04f07949356f1cd95d4f8fdbededf4ab5c21e
With this patch applied:
=== RUN TestBuildMultiStageOnBuild
--- PASS: TestBuildMultiStageOnBuild (6.74s)
=== RUN TestBuildUncleanTarFilenames
--- PASS: TestBuildUncleanTarFilenames (2.49s)
=== RUN TestBuildMultiStageLayerLeak
--- PASS: TestBuildMultiStageLayerLeak (5.14s)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This message was missing the name of the plugin, resulting in
plugin_test.go:92: timeout hit after 30s: plugin %!q(MISSING) exists
On failing tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Since Go 1.7, context is a standard package. Since Go 1.9, everything
that is provided by "x/net/context" is a couple of type aliases to
types in "context".
Many vendored packages still use x/net/context, so vendor entry remains
for now.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
