Tells the proxy not to do anything with this container. We set it when
running weaveexec/weave/etc containers, so that the weave script works
through the proxy.
This is quite hilarious...
$BASE_IMAGE is not defined in config.sh. So running this test would
actually attempt to run something like
docker -H=... run -e WEAVE_CIDR=10.2.1.4/24 grep ^1$ /sys/class/net/ethwe/carrier
i.e. it would try to run the 'grep' image.
So why does this not fail all the time?
1) 610_*.sh defines $BASE_IMAGE.
2) 620_*.sh builds a 'grep' image.
If either of these tests are included in the same test run before
650_*.sh, then the latter will succeed.
Throw in our fabulous CircleCI scheduler, which distributes tests
according to their execution time, and you end up with sporadic
failures.
Fixes#938.
It's ugly, but beats arg-parsing, inspecting the container and piecing
the address together from exposed ports.
We could just use the host from DOCKER_HOST, but that will fail in the
case of a host with multiple IPs, where the proxy only listens on one.
We erroneously assumed that `docker start` returned the full container
id. It doesn't and as a result we populated DNS with records with ids
other than full container ids. And that's also what we told IPAM. As a
result, DNS and IPAM didn't clean up after the container's death,
resulting in stale DNS entries and leaked IPs.
Fixes#881.
If the name cannot be resolved, getent fails, which in turn causes
assert_dns_record to just return with a non-zero status at that point,
which causes the whole test to just terminate with a non-zero status,
but no indication whatsoever what had gone wrong.
Caveats:
* TLS files must be present on the target server (and readable)
* TLS file paths cannot contain spaces
* TLS file paths must be absolute (i.e. cannot be relative)
* Bash argument parsing is terrible
The code is quite messy, but particularly the argument parsing and
volume-mounting. Also, it doesn't support args with spaces, or
non-absolute file-paths.
Adam Harrison