Re: [Discuss] num_tokens default in Cassandra 4.0

Why do we have to assume random assignment? Because token allocation only works once you have a node in RF racks. If you don't bootstrap nodes in alternating racks, or just never have RF racks setup (but more than one rack) it's going to be random. Whatever default we choose should be a safe ch

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

Behaviours don't have to be switched only with a new protocol version; it's possible to support optional feature/modifier flags, the support for which is negotiated with a client on connection. A protocol version change seems reasonable to limit to major releases, but a protocol feature seems p

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

CustomPayload should be used to provide customization via a custom query handler (that is outside of Cassandra source). Supporting custom timeout per query is a new feature. It is more clear to assign a dedicated query flag. In V5, the available number of query flags expanded from 8 (in V4 and prio

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

Given the JIRA in question, if you want to override the timeout to lower it, then the worst case if not supported yet is that you get the default timeout. So this then makes me wonder "is there a way to add metadata to a message which is ignored if unknown" (aka forward compatibility). Skimming t

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

A few notes: - Protocol changes add work to the rest of the ecosystem. Drivers have to update, etc. - Nobody expects protocol changes in minors, though it's less of a concern if we don't deprecate out the older version. E.g. if 4.0 launches with protocol v4 and protocol v5, and then 4.0.2 adds pro

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

I don't know the technical answer, but I suspect two motivations for doing new protocol versions in major releases could include: * protocol changes can be tied to feature changes that typically come in a major release. * protocol changes should be as infrequent as major releases. Each new protoc

[DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

[Moving to new message thread] Thanks for bringing this up, Jordan. IIRC, this was more a convention than a technical reason. Though I could be completely misremembering this. -- Forwarded message - From: Jordan West Date: Wed, Feb 19, 2020 at 10:13 AM Subject: Re: 20200217 4.0

Re: 20200217 4.0 Status Update

Moving to a new thread. On Wed, Feb 19, 2020 at 10:13 AM Jordan West wrote: > On Mon, Feb 17, 2020 at 12:52 PM Jeff Jirsa wrote: > > > > > beyond the client proto change being painful for anything other than > major > > releases > > > > > This came up during the community meeting today and I wa

Re: 20200217 4.0 Status Update

On Mon, Feb 17, 2020 at 12:52 PM Jeff Jirsa wrote: > > beyond the client proto change being painful for anything other than major > releases > > This came up during the community meeting today and I wanted to bring a question about it to the list: could someone who is *very* familiar with the cli

Re: Testing out JIRA as replacement for cwiki tracking of 4.0 quality testing

I went ahead and imported the rest of the issues from cwiki and setup assignee = shephard, reviewers == contributors. Epic in JIRA Query in JIRA of the tickets created: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20a

Re: [Discuss] num_tokens default in Cassandra 4.0

+1 for 8 + algorithm assignment being the default. Why do we have to assume random assignment? If someone turns off algorithm assignment they are changing away from defaults, so they should also adjust the num tokens. -Jeremiah > On Feb 18, 2020, at 1:44 AM, Mick Semb Wever wrote: > > -1 >

Re: [Discuss] num_tokens default in Cassandra 4.0

> > Discussions here and on slack have brought up a number of important > concerns. Sounds like we're letting the perfect be the enemy of the good. Is anyone arguing that 256 is a better default than 16? Or is the fear that going to 16 now would make a default change in, say, 5.0 more painful? O

Re: [Discuss] num_tokens default in Cassandra 4.0

In case it helps move the decision along, we moved to 16 vnodes as default in Nov 2018 and haven't looked back (many clusters from 3-100s of nodes later). The testing we did in making that decision is summarised here: https://www.instaclustr.com/cassandra-vnodes-how-many-should-i-use/