[ https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400082#comment-16400082 ]
Oleksandr Shulgin edited comment on CASSANDRA-5836 at 3/15/18 8:35 AM: ----------------------------------------------------------------------- {quote}system.available_ranges works off keyspaces, so rebuild will still work fine as long as you didn't add RF before provisioning the DC (e.g you didn't bootstrap the NTS keyspaces){quote} You are correct, I had a false assumption here. But then I don't see at all where does the recommendation to set {{auto_bootstrap=false}} for new DC come from? I believed the reason was that {{nodetool rebuild}} won't work otherwise, but it's not the case apparently. If we can simply drop this recommendation from the docs that would be a great thing, IMO. By following the doc in its current form it is not unlikely that one can accidentally add some nodes with {{auto_bootstrap=false}} to *existing* DC, simply by messing up the DC suffix parameter. With the default setting of {{auto_bootstrap} such a configuration error is mostly harmless and is easy to rollback. {quote}> At the same time, new cluster startup process can be arbitrarily complex No, it can't. {quote} Unfortunately, it already is. For example, look at our home-grown automation code to create new Cassandra clusters on AWS: https://github.com/zalando-stups/planb-cassandra/blob/master/planb/create_cluster.py That's already close to 1,000 lines of Python. {quote}Cassandra is hard enough to use as it is, and we really shouldn't be making operations more complex.{quote} Creating a new cluster is the operation with the least possible potential impact of all, and you do it only once in a lifetime of a cluster. I would go as far as saying it doesn't even belong to "ops". Restarts, upgrades, bootstrapping new nodes and DCs: these are the operations and we shouldn't make "introduction to Cassandra" easier at the cost of making *these* more complex or risky. {quote}Far more logical to be able to say that "All nodes will respect the auto_bootstrap setting regardless of their configuration". The only caveat is that the first node won't bootstrap,..{quote} That's already a contradiction, don't you think? And more precisely it should be spelled as "if a node *believes* it is the very first one". A big question to me still: can this be done in the code reliably? {quote}... but to users this is irrelevant and they don't need to know about it.{quote} This attitude is exactly what makes Cassandra hard to use in my experience. :( I cannot even count the number of times when I had to dive deeply into the source code trying to figure some detail which was not properly documented, because the devs thought the same: users don't need to know about it... was (Author: oshulgin): {quote}system.available_ranges works off keyspaces, so rebuild will still work fine as long as you didn't add RF before provisioning the DC (e.g you didn't bootstrap the NTS keyspaces){quote} You are correct, I had a false assumption here. But then I don't see at all where does the recommendation to set {{auto_bootstrap=false}} for new DC come from? I believed the reason was that {{nodetool rebuild}} won't work otherwise, but it's not the case apparently. If we can simply drop this recommendation from the docs that would be a great thing, IMO. By following the doc in its current form it is not unlikely that one can accidentally add some nodes with {{auto_bootstrap=false}} to *existing* DC, simply by messing up the DC suffix parameter. With the default setting of {{auto_bootstrap} such a configuration error is mostly harmless and is easy to rollback. {quote}> At the same time, new cluster startup process can be arbitrarily complex No, it can't. {quote} Unfortunately, it already is. For example, look at our home-grown automation code to create new Cassandra clusters on AWS: https://github.com/zalando-stups/planb-cassandra/blob/master/planb/create_cluster.py That's already close to 1,000 lines of Python. {quote}Cassandra is hard enough to use as it is, and we really shouldn't be making operations more complex.{quote} Creating a new cluster is the operation with the least possible potential impact of all, and you do it only once in a lifetime of a cluster. I would go as far as saying it doesn't even belong to "ops". Restarts, upgrades, bootstrapping new nodes and DCs: these are the operations and we shouldn't make "introduction to Cassandra" easier at the cost of making *these* more complex or risky. {quote}Far more logical to be able to say that "All nodes will respect the auto_bootstrap setting regardless of their configuration". The only caveat is that the first node won't bootstrap,..{quote} That's already a contradiction, don't you think? And more precisely it should be spelled as "if a node *believes* it is the very first one". A big question to me still: can this be done reliably? {quote}... but to users this is irrelevant and they don't need to know about it.{quote} This attitude is exactly what makes Cassandra hard to use in my experience. :( I cannot even count the number of times when I had to dive deeply into the source code trying to figure some detail which was not properly documented, because the devs thought the same: users don't need to know about it... > 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