clarify rmpeer caution in docs
- "You cannot call `weave rmpeer` on more than one host" - yes you can, but you must not call it on more than one host *for the same peer* - `weave forget` has nothing to do with this - "results in duplicate IPs" - no, it causes duplicate address range assignments - "the address is reassigned" - it's the address *range* that is reassigned - "claim" is a new and confusing term -> drop - "address space" -> "address range" (that's what it's called elsewhere)
This commit is contained in:
1 parent
a1fb08216e
commit
1f4165c132
1 file changed
+13
-13
@@ -37,22 +37,22 @@ name. Alternatively, you can supply a peer name as shown in `weave status`.
|
||||
|
||||
### <a name="caution-rmpeer"></a>Caution###
|
||||
|
||||
You cannot call `weave rmpeer` on more than one host. The address
|
||||
space, which was owned by the stale peer cannot be left dangling, and
|
||||
as a result it gets reassigned. In this instance, the address is
|
||||
reassigned to the peer on which `weave rmpeer` was run. Therefore, if
|
||||
you run `weave forget` and then `weave rmpeer` on more than one host
|
||||
at a time, it results in duplicate IPs on more than one host.
|
||||
Do not invoke `weave rmpeer` for the same peer on more than one
|
||||
host.
|
||||
|
||||
Once the peers detect the inconsistency, they log the error and drop
|
||||
The removed peer's address range cannot be left dangling and is
|
||||
therefore reassigned to the peer on which `weave rmpeer` was
|
||||
run. Consequently, if you run `weave rmpeer` for the same peer on more
|
||||
than one host, the removed peer's address range will be owned by
|
||||
multiple peers.
|
||||
|
||||
Once the peers detect this inconsistency, they log the error and drop
|
||||
the connection that supplied the inconsistent data. The rest of the
|
||||
peers will carry on with their view of the world, but the network will
|
||||
not function correctly.
|
||||
|
||||
Some peers may be able to communicate their claim to the others before
|
||||
they run `rmpeer` (i.e. it's a race), so what you can expect is a few
|
||||
cliques of peers that are still talking to each other, but repeatedly
|
||||
dropping attempted connections with peers in other cliques.
|
||||
not function correctly. Depending on the timing of the `rmpeer` and
|
||||
the communication between peers, several peer cliques may form -
|
||||
groups of peers that are talking to each other, but repeatedly drop
|
||||
attempted connections with peers in other cliques.
|
||||
|
||||
**See Also**
|
||||
|
||||
|
||||
Reference in new issue
Block a user