[ipam] hang on weave launch when other peers are unresponsive

[bboreham]

Having previously done weave expose, stopping weave and re-starting with:

weave launch -iprange 10.2.1.0/24 192.168.48.11

hung, because the other peer wasn't responding.

This is because the weave script's ipam_claim makes http calls which hang, with no timeout and no explanation to the user what is happening.

[rade]

I thought the decision here not to have a timeout was quite deliberate, wasn't it?

[bboreham]

I would agree we decided not to put a timeout inside the allocator, but am less clear whether we expected to do it upstream in the weave script. Unfortunately, in places like weave run, we have already started the container so it's hard to recover nicely.

Hanging weave launch until consensus is reached was not something I had thought about. Especially when it doesn't happen first time, only on re-launch.

At minimum, there ought to be some sort of hint to the user what is happening. Currently, weave status will say something like:

Paxos: Nodes known: 1, Quorum size: 2

when it is waiting for consensus. Which isn't crystal clear.

[bboreham]

I changed that message in 70b595c to:

Awaiting consensus: Nodes known: 1, Quorum size: 2

[bboreham]

Related: #666, wherein the OP takes the opposite view

[bboreham]

I think this issue is the same as #1083, fixed by #1104