search

weaveworks / weave

Simple, resilient multi-host containers networking and more.
https://www.weave.works
Apache License 2.0
6.62k stars 668 forks source link

Persist discovered peers #2187

Open awh opened 8 years ago

awh commented 8 years ago

When you manually add a new peer to an existing network it is not desirable to go back to the existing peers and do weave connect (assuming that persists as per #2186) - it would be better if existing peers remembered the new peer automatically.

rade commented 8 years ago

The purpose of weave connect is to enable adding of a peer when the existing peers sit behind a firewall, i.e. the new peer is reachable from the existing peers but not vice versa.

awh commented 8 years ago

That is a purpose. We are also tentatively recommending it in the ops guide as a way of getting maximum reboot resilience in manually configured deployments, to which you responded that we should consider persisting discovered peers instead.

rade commented 8 years ago

Yes, I know I said that.

I would quite like to know when we are going to forget about a discovered peer.

rade commented 8 years ago

btw, the recommendation in the ops guide only works if the peer isn't behind a firewall that blocks inbound connections. It also assumes that operators know the external IP(s).

awh commented 8 years ago

I know I said that.

I'm just including it for the benefit of those who weren't part of the conversation.

I would quite like to know when we are going to forget about a discovered peer.

Indeed - thinking about that is part of this issue.

btw, the recommendation in the ops guide only works if the peer isn't behind a firewall that blocks inbound connections. It also assumes that operators know the external IP(s).

True. Ops guide doesn't consider such deployments yet!

rade commented 8 years ago

Yes, I know I said that.

Actually, I didn't say that. I observed in the ops guide PR that "we'd benefit from connect and forget propagating through the cluster." Which is not the same as persisting discovered peers, and doesn't suffer from the garbage collection issue. Though, on reflection, my observation was ill-informed, given my comment above. By contrast, persisting discovered peers in theory would allow us to eliminate connect/forget from the current ops guide completely since the guide does not cover the scenarios for which connect/'forget' were designed.