Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persist discovered peers #2187

Open
awh opened this issue Apr 18, 2016 · 6 comments
Open

Persist discovered peers #2187

awh opened this issue Apr 18, 2016 · 6 comments

Comments

@awh
Copy link
Contributor

awh commented Apr 18, 2016

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.

@awh awh added this to the 1.6.0 milestone Apr 18, 2016
@awh awh mentioned this issue Apr 18, 2016
@rade
Copy link
Member

rade commented Apr 18, 2016

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
Copy link
Contributor Author

awh commented Apr 18, 2016

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
Copy link
Member

rade commented Apr 18, 2016

Yes, I know I said that.

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

@rade
Copy link
Member

rade commented Apr 18, 2016

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
Copy link
Contributor Author

awh commented Apr 18, 2016

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
Copy link
Member

rade commented May 31, 2016

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.

@awh awh modified the milestones: 1.7.0, 1.6.0 Jun 9, 2016
@rade rade modified the milestones: 1.8.0, overflow Oct 7, 2016
@bboreham bboreham unassigned awh Oct 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants