Administrative function to remove peer

[awh]

It's not currently possible to instruct weave to forget about a peer that was specified via weave launch or weave connect. This causes problems for users with dynamic environments where peers can go away forever; their only recourse currently is to restart the weave network leaving out the decommissioned peer.

Add a script command that instructs the router to forget a specified peer:

weave forget <CIDR>

'Forget' is suggested for the command name as 'disconnect' implies simply closing a connection; forget removes the peer from weave's internal list of known seeds. Any advance on a better name @rade?

[awh]

Invite @fermayo

[bboreham]

The original motivation for this feature was to be used on one peer to forget about one address previously specified to that peer. But what if it's inconvenient to remember which peer was told about which other peer? Maybe 'forget' should work from any peer in the network.

This would require a way to uniquely identify a peer; IP addresses do not do this in the presence of NAT. Perhaps nicknames could be used?

A 'distributed forget' as I have described might have complex semantics under network partition.

[awh]

I think in the long term that could be useful - perhaps we could split it off as a separate ticket? I'm keen to get an MVP of this out in the next stable release if possible...

[rade]

'connect' adds to the "list of IP addresses this peer should always attempt to connect to". It makes sense to have an inverse operation for that. Let's not boil the ocean here.

[kulki]

How is this feature supposed to work? Suppose if I have 10 nodes in my weave network and I want to remove one from the network, do I need to run 'weave forget ' from each of the other 9 nodes?
It would be helpful, as mentioned by @bboreham, if i could run 'weave forget ' from only one of the other nodes.

Following is the experiment I did. Note: Auto discovery is ON (default)
I started 'weave launch' from 3 machines m1, m2 & m3.
On m1: I ran 'weave connect m2' and 'weave connect m3'. Now all were part of the network.
Then I ran 'weave reset' on m2 followed by 'weave forget m2' on m1.
Then on m2: I ran 'weave launch'. Immediately m2 joined the network automatically as if 'forget' had no effect.

In the second run, I 'weave reset' on m2 and 'weave forget m2' on both m1 and m3 and then I ran 'weave launch' on m2. This time m2 did not join the network. I got what I desired. But this is too tedious if have more peers.

In the first case I am wondering if what I think below is happening.
Even though m1 forgot m2, m3 did not and due to dynamic discovery m3 brought m2 into the network and propagated it to m1 as well. If this indeed is the case, can't we propagate what m1 forgot? Or if both tried propagating conflicting things - ie m1 saying I should foget m2 and m3 saying m2 is my peer, then can't the latest action (forget m2 in this case) take priority?

[hugespoon]

This still appears to be the case. If I have 10 nodes, this becomes nearly impossible without doing full restarts.

[rade]

It doesn't require full restarts. You remove a node with weave reset on the node itself, followed by weave forget <removed-node> on all the remaining nodes.