The same piece of GossipData can be shared and subject to different
Merge operations. We either need to copy the data when we share it, or
create copies on modification, i.e. copy-on-write.
We choose the latter, since it is more efficient and there is just one
mutating operation.
Fixes#1697.
This is mostly a matter of moving some files, changing package names,
changing some imports, and changing some type references.
We duplicate the odd constant & global var, and the intmac/macint
functions, since neither 'router' or 'mesh' nor, really,' common' are
a natural home for 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.
Adam Harrison