- One unique file to list all dependencies and dependencies' versions (except Go, currently defined in `build/Dockerfile`).
- Custom versions can now be injected into Vagrant VMs.
- Vagrant dev VMs, Vagrant test VMs, and `run-integration-tests.sh` all source from `DEPENDENCIES`, to keep things 'DRY'.
- Vagrant versions can be overriden using environment variables, like it was possible in `run-integration-tests.sh`.
The intention, per the comments, is that host1 should claim from host2.
But host2 and host3 can carve up the space either way round. If host1
claims from host3 then there is a race whether anyone finds out about
it.
Adding a 'prime' on host2 ensures the space is all owned by host2 at that point.
This should be useful when we just want to type one make integration-tests / ./run-integration-tests command to make/start VMs/configure them/test, but also investigate potential failures afterwards.
This should make development easier by allowing developers to set HOSTS in their calling shell, and re-use the value for this env. var. when calling individual test scripts, e.g.:
```
cd test
eval $(./run-integration-tests.sh setup)
./200_dns_test.sh
```
CircleCI keeps 10 nodes in order to speed up the build, but the default is 3, as this is the minimum required to run any test. This should make more sense as a default for a developer to quickly start an environment and iterate.
This way, Vagrant VMs and cloud-provided VMs are configured in the exact same way, hence avoiding configuration drift and subtle bugs associated to different versions of software.
Provisioning and configuration being expensive time-wise, we create Google Cloud Platform images for each Docker/Kubernetes/Kubernetes CNI versions triple, and configure these once (instead of for each build), and then re-use these in subsequent builds, effectively implementing a 'cache' of images.
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
If the machine coordinating the test runs does not have jq, then test #175 fails with:
> test #1 "weave_on test-0.lon1.weave-net report | jq -r '.Router.Targets[] | tostring' | sort" failed:
> expected "test-1.lon1.weave-net
> test-2.lon1.weave-net"
> got nothing
This change completely removes the dependency on jq to make the test more robust and avoid potential confusion.
Test hard-codes a string containing '\n' and then expects echo
to interpret it as a newline, which it does not without the -e option.
This fixes flaky test runs like the below:
>>> Running /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh on [138.68.153.213 138.68.149.186]
>>> Test /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh finished after 12.4 secs with error: exit status 1
test #5 "direct_peers 138.68.149.186 | sort" failed:
expected "138.68.153.213\n138.68.149.186"
got "138.68.149.186\n138.68.153.213"
Enabled hairpin mode on vethwe-bridge was one of the root causes
for installing looping flows in the fastdp mode.
Also, it confused the weave custom L2 bridge, as the bridge treats
a bounced back packet, e.g. ARP brodcast request, as a local one
(the case for "Captured a packet associated with remote host").
Bryan Boreham