[ 
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383984#comment-16383984
 ] 

Robert Coli edited comment on CASSANDRA-5836 at 3/2/18 7:02 PM:
----------------------------------------------------------------

I should probably join #cassandra-dev IRC and chat about this there, but I'd 
like to refer people to this comment up-ticket :

https://issues.apache.org/jira/browse/CASSANDRA-5836?focusedCommentId=13727032&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13727032

Nobody really seems to understand why it's not safe for a seed node to 
bootstrap, because the workaround is to temporarily pretend the node isn't a 
seed and to bootstrap it. Usually one doesn't even inform the other nodes that 
it temporarily isn't a seed, and nothing unsafe seems to happen.

I feel like clarity here starts with explaining in what cases a Seed node is 
actually "Seeding" and what "Seeding" means and does not mean. My understanding 
is that the 'seed node' role has a significant initial-topology-discovery 
responsibility which I have not seen mentioned in recent discussions. This 
dovetails with needing to understand seed node behavior in the "restoring from 
snapshot" case, where the topology is known from existing cluster information 
and therefore may or may not "need" to be discovered from a seed. Also, as of 
my last knowledge of this code, a given node will gossip with a Seed node more 
frequently than its other peers, which I believe is "just an optimization of 
gossip" but seems notable.

I also recall past dev discussion (with driftx?) suggesting that the "correct" 
solution in their view is an external seed provider.

So in summary my understanding of the complete responsibilities of a seed, 
independent from whether it's serving as a bootstrap source or bootstrapping 
itself :
1) provide other nodes which consider it a seed with initial topology

2) provide "faster" topology updates to nodes which have me listed in their 
seed provider

The minimum requirement for a new node joining the cluster seems to be a single 
seed node that can inform it of topology in a timely manner. If that's correct 
and we imagine that all nodes use a seed provider that always returns at least 
one available node that can fulfill that role, the problem (?) of not being 
able to bootstrap seed nodes seems to disappear?


was (Author: rcoli):
I should probably join #cassandra-dev IRC and chat about this there, but I'd 
like to refer people to this comment up-ticket :

https://issues.apache.org/jira/browse/CASSANDRA-5836?focusedCommentId=13727032&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13727032


Nobody really seems to understand why it's not safe for a seed node to 
bootstrap, because the workaround is to temporarily pretend the node isn't a 
seed and to bootstrap it. Usually one doesn't even inform the other nodes that 
it temporarily isn't a seed, and nothing unsafe seems to happen.

I feel like clarity here starts with explaining in what cases a Seed node is 
actually "Seeding" and what "Seeding" means and does not mean. My understanding 
is that the 'seed node' role has a significant initial-topology-discovery 
responsibility which I have not seen mentioned in recent discussions. This 
dovetails with needing to understand seed node behavior in the "restoring from 
snapshot" case, where the topology is known from existing cluster information 
and therefore may or may not "need" to be discovered from a seed. Also, as of 
my last knowledge of this code, a given node will gossip with a Seed node more 
frequently than its other peers, which I believe is "just an optimization of 
gossip" but seems notable.

I also recall past dev discussion (with driftx?) suggesting that the "correct" 
solution in their view is an external seed provider.

So in summary my understanding of the complete responsibilities of a seed, 
independent from whether it's serving as a bootstrap source or bootstrapping 
itself :
#) provide other nodes which consider it a seed with initial topology

#) provide "faster" topology updates to nodes which have me listed in their 
seed provider

The minimum requirement for a new node joining the cluster seems to be a single 
seed node that can inform it of topology in a timely manner. If that's correct 
and we imagine that all nodes use a seed provider that always returns at least 
one available node that can fulfill that role, the problem (?) of not being 
able to bootstrap seed nodes seems to disappear?

> Seed nodes should be able to bootstrap without manual intervention
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-5836
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Bill Hathaway
>            Priority: Minor
>
> The current logic doesn't allow a seed node to be bootstrapped.  If a user 
> wants to bootstrap a node configured as a seed (for example to replace a seed 
> node via replace_token), they first need to remove the node's own IP from the 
> seed list, and then start the bootstrap process.  This seems like an 
> unnecessary step since a node never uses itself as a seed.
> I think it would be a better experience if the logic was changed to allow a 
> seed node to bootstrap without manual intervention when there are other seed 
> nodes up in a ring.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to