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.
29 lines
661 B
Bash
Executable File
29 lines
661 B
Bash
Executable File
#! /bin/bash
|
|
|
|
. ./config.sh
|
|
|
|
start_suite "IPAM ring seed mismatch"
|
|
|
|
weave_on $HOST1 launch-router --no-discovery
|
|
weave_on $HOST2 launch-router --no-discovery
|
|
weave_on $HOST3 launch-router --no-discovery
|
|
|
|
# Do some allocations to get the ring initialized on two hosts
|
|
start_container $HOST1
|
|
start_container $HOST2
|
|
|
|
# Connect 2 to 3 and allocate so they will each have half the ring
|
|
weave_on $HOST2 connect $HOST3
|
|
start_container $HOST3
|
|
|
|
# More allocations on 1 to increase the version number
|
|
start_container $HOST1
|
|
start_container $HOST1
|
|
|
|
weave_on $HOST1 connect $HOST3
|
|
|
|
# Check that weave on 3 is still running
|
|
assert_raises "weave_on $HOST3 status"
|
|
|
|
end_suite
|