[
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: [email protected]
For additional commands, e-mail: [email protected]
