Previously, the proxy would run the weave script in ways that did
not run the weaver executable. Now they can. This is a problem because
of the contortions involved in using golang's code coverage support
in the integration tests, which require the weaver command line args to
be slightly mangled.
This means:
* The 'weave' netdev is an OVS datapath
* The weave router container runs with --net=host in order to access
the datapath.
* The MTU is set to a smaller value, to allow vxlan encapsulation.
Setting the WEAVE_NO_FASTDP environment variable disables these
things, effectively running the router without fast datapath. It is
an environment variable rather than an option to 'weave launch'
because it takes effect in create_bridge, which is called from many
subcommands, and it doesn't seem practical to add option processing to
all of them.
These are needed to support vxlan encapsulation. In a vxlan packet,
the only place we can straightforwardly hold the source and
destination peer identifiers used by the weave router is in the
24-bit VNI (vxlan network identifier) field. This gives us 12 bits to
indicate a peer. The resulting limit of 4096 peers on a weave network
does not seem like a problem in the near future. But it does mean
that decentralized allocation makes collisions fairly likely even in
weave networks of sizes that are common today. Fortunately, the
problem is much more tractable than IPAM because we can detect when
collisions occur and take action to resolve them.
When a container died before we got into the allocation code (inside
the allocator run loop) we would not cancel the allocation since the
container death event will have been processed by the allocator before
it had any knowledge of the container.
The fix is to move the container-aliveness check inside the allocation
code. That way we still detect the death even if the event has already
flown past.
We only need to perform the check once, since any subsequent death
will result in an event that is processed by the allocator when it has
recorded the container in its state.
Fixes#1459.
There are three significant changes here:
- rewrite ring.ErrDifferentSeeds errors
- remove the pre-checking of ranges and instead rewrite
ring.ErrDifferentRange errors
- don't pruneNicknames() and signal ringUpdated() when there was an
error
We don't rewrite other errors since our current belief is that only
ErrDifferentSeeds and ErrDifferentRange can arise from user error.
Adam Harrison