[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401328#comment-16401328
]
Kurt Greaves commented on CASSANDRA-5836:
-----------------------------------------
bq. But then I don't see at all where does the recommendation to set
auto_bootstrap=false for new DC come from?
That was always a datastax recommendation so I don't know where it came from.
As I'm sure you're aware, the Cassandra docs are quite sparse in the operations
area, but all of this should be documented properly.
bq. Unfortunately, it already is
I'm well aware of that. I'm saying it shouldn't be. And we certainly shouldn't
be making a bad situation worse.
bq. 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?
No, I don't think so. Caveat was probably the wrong word here, because it's not
a caveat. It's literally that it's *irrelevant* what the first node does. If
auto_bootstrap is true for the first node, it's a no-op, if it's false, it's a
defined no-op. The first node still respects auto_bootstrap, but the result is
the same for either true or false. This is always going to be the case.
If it can be done by hand it can be done by code. The first node would be
defined as a node that only has itself as a seed, and no existing knowledge of
any other node in the cluster. This is quite straightforward (but not part of
my patch yet).
bq. 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...
I think you misunderstand. It's not that attitude that makes Cassandra hard to
use, it's the fact that things get implemented without documentation and
problems get missed when considering the effects on all aspects of Cassandra,
because it's so large and complex. The only reason you need to dive into the
code/jira tickets is because there's no accurate documentation for what you're
looking for, or reasoning for why something behaves as it does.
My point is precisely that users don't need to know about it, therefore they
shouldn't have to dig into the code. If they have to dig into the code the
implementation is likely wrong. We should be aiming to make it so that no user
ever has to even consider looking in the code to figure out how seeds work, let
alone even the documentation. It literally should not even cross their mind
short of the fact that they have to set some seeds.
> 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]
