Fixes:
- `test/run-integration-tests.sh:160:75: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:265:56: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:295:61: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:309:49: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh:316:41: arithmetic expressions must consist of names and numbers`
- `test/run-integration-tests.sh: run shfmt -i 4 -w test/run-integration-tests.sh`
See also: https://circleci.com/gh/weaveworks/weave/8685
Renamed to "is_plugin_v1_enabled" and "is_plugin_v2_enabled".
Improve weave status and weave launch* err message when plugin-v2 is running
```
$ weave launch
Docker plugin "weaveworks/net-plugin" is running; Aborting.
$ weave status
<..>
Service: plugin (v2)
DriverName: weaveworks/net-plugin
```
This simplifies the following:
- plugin-v2 does not need to start "plugin" as a separate process, thus
Docker is able to properly restart plugin-v2 in a case of any child
process failing.
- No need for weaveplugin container.
plugin is enabled by default when running "weave launch". when starting
only the router, you should pass "--plugin" parameter to enable it.
The env var WEAVE_NO_PLUGIN is no more.
Since 1.12.0, `docker inspect -f "{{ .NetworkSettings.Networks.<network>.Aliases }}"` also returns the container's short ID.
See also: https://github.com/docker/docker/blob/master/CHANGELOG.md
> 1.12.0 (2016-07-28)
> Networking
> Add container's short-id as default network alias #21901
Upgrading `docker/docker-py` to 1.9.0-rc2 effectively relaxes test assertions for:
- `tests/integration/network_test.py#test_connect_with_aliases`
- `tests/integration/network_test.py#test_create_with_aliases`
which do something equivalent to:
```
$ docker network create net1
$ docker run --name c1 -d busybox top
$ docker network connect --alias foo --alias bar net1 c1
$ docker inspect -f "{{ .NetworkSettings.Networks.net1.Aliases }}" c1
[foo bar e52bf50e5ee7]
```
allowing us to be consistent with the above change.
In 1.8.1, the below fails as the container's short ID would be present:
```
self.assertEqual(
container_data['NetworkSettings']['Networks'][net_name]['Aliases'],
['foo', 'bar'])
```
In 1.9.0-rc2, the below passes as the container's short ID is ignored:
```
aliases = (
container_data['NetworkSettings']['Networks'][net_name]['Aliases']
)
assert 'foo' in aliases
assert 'bar' in aliases
```
Without this commit, `kubeadm` typically upgrades whichever version of Kubernetes is installed, sometimes leading to conflicts in between components' version.
This fixes the issue behind #2876 and should avoid build failures like [weave/8373](https://circleci.com/gh/weaveworks/weave/8373).
- 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.
Bryan Boreham