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.
This is an early detector for a multitude of other symptoms, some of
which cause panics.
When creating the ring we record the paxos-supplied normalised list of
peers used for seeding. This subsequently gets gossipped around as
part of the Ring data structure, and checked in ring.Merge that it is
the same for the recipient.
There are some subtleties due to the desire to maintain backward
compatibility and deal with empty rings
- The gossip gob decoder will ignore the Ring.Seeds field when an old
weave receives a Ring from a new weave. So everything on the old
weave will just continue to work as before.
- The gossip gob decoder will set the Ring.Seeds field to nil when a
new weave receives a Ring from an old weave. We therefore omit the
seed equivalence check when the received Seeds slice is empty.
- Our ring may not have any seeds - either because it is empty or was
created from a ring received from an old weave. We therefore a) omit
the seed equivalence check in that situation, and b) set our seeds
to those received. Note that this allows us to learn about the seeds
well after ring creation - a situation which may arise when
receiving gossip from a mixture of old and new weaves.
Fixes#1463.
David Wragg