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

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

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

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

[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

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

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:

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?

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/