On Fri, Feb 23, 2018 at 10:12 AM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote:
> On Fri, Feb 23, 2018 at 7:02 PM, Jeff Jirsa <jji...@gmail.com> wrote: >> >> Yes, seeds don't bootstrap. But why? I don't think I ever seen a >>> comprehensive explanation of this. >>> >>> The meaning of seed in the most common sense is "connect to this host, >> and use it as the starting point for adding this node to the cluster". >> >> If you specify that a joining node is the seed, the implication is that >> it's already a member of the cluster (or, alternatively, authoritative on >> the cluster's state). Given that implication, why would it make sense to >> then proceed to bootstrap? By setting it as a seed, you've told it that it >> already knows what the cluster is. >> > > Well, there is certain logic in that. However, bootstrap is about > streaming in the data, isn't it? And being seed is about knowing the > topology, i.e. which nodes exist in the cluster. There is actually 0 > overlap of these two concerns, so I don't really see why a seed node > shouldn't be able to bootstrap. Would it break anything if it could, e.g. > if you're explicit about it and request auto_boostrap=true? > > I dont *think* it would break anything, but the more obvious answer is just not to list the node as a seed if it needs to bootstrap. This comes up a lot, and it's certainly one of those rough operator edges that we can do better with. There's no strict requirement to have all of the seeds exactly the same in a cluster, so if you need to bootstrap a new seed, just join it with it not a seed, then bounce it to make it think it's a seed after it's joined. The easier answer is probably "give people a way to change seeds after they're running", and it sorta exists, but it's hard to invoke intentionally. We should just make that easier, and the rough edges will get a little less rough.
