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.
"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.
Obtain the version and latest_release tag commit hashes before changing
into the cloned repository so that all tagging and pushing happens on
the outer repository.
The publish stage has been split into two pieces - a draft step that
creates a draft version release in Github and a publish step that
publishes the draft, updates `latest_release` and pushes images to
DockerHub.
It is also possible to specify `--pre-release` to draft. Once published
such a release will be marked with a prominent warning in GitHub;
additionally we do not update `latest_release` in GitHub nor push an
update to the `latest` tag in DockerHub.
To support arbitrarily named pre-releases we no longer impose any
restrictions on the format of the most recent annotated tag - instead we
expect to find a single annotated tag pointing at HEAD of the current
branch and assume this is the version to release.
We would like to have a stable URL for the most recently released
script, so that we can mention it in the README and people can use it
in update scripts.
Since GitHub's releases/latest URL redirects, and anyway doesn't work
for downloads, we have to create (possibly delete first) a release
tagged "latest_release" and update it.
Before, this could fail without a message if there was a changelog but
no matching line.
Also change the changelog format
== Release v0.0.1
to
== Release 0.0.1
Bryan Boreham