Mount iptables lock file in weave-kube
iptables uses the file `/run/xtables.lock` so that if changes are
under way, another instance of the iptables command can wait till it
is finished.
We need to mount the lock file from the host to the container in order
for this mechanism to work at all.
Note we rely on kubelet touching the file before running any pods -
see https://github.com/kubernetes/kubernetes/pull/47212
Currently our `Makefile` and `bin/release` scripts are such that we effectively do the following when releasing:
```
publish:
for arch in [amd64 arm arm64]:
sub-publish:
clean_bin
publish
plugin_publish
```
which leads the Docker v2 plugin to contain `arm64` binaries even though we target `amd64`.
Swaping `publish` and `plugin_publish` is a simple way to avoid this.
Given `proxy` & `router` processes have been merged, `launch-proxy`,
`launch-router`, `stop-proxy`, `stop-router` do not make sense any more, and
should just be `launch` and `stop` with the appropriate flags.
"docker plugin" does not support tagging plugin images, therefore
we need to build plugin images two times - one for :latest and
for :$(WEAVE_VERSION).
Pushing of :latest happens only if $UPDATE_LATEST is not false.
There may be situations when Terraform/Ansible/etc. fail to provision test machines.
In these cases, we want to fail fast instead of waiting until we time out in circle-test-pre and circle-test-smoke.
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.
Makes what the build does explicitly and helps for potential debugging.
Also reminds us that we are skipping these files, so that we ultimately shfmt them and stop lint-ignoring them.
Multiweave now creates a temporary bridge with an IP alias per router
in the host netns, and overrides the router to bind to that specific
IP for weave protocol and data traffic and http control.
Bryan Boreham