Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

[Jaydeep Chovatia]

Sure, Caleb. I will include the work as part of CASSANDRA-19534
 in the CEP-41.

Jaydeep

On Fri, May 3, 2024 at 7:48 AM Caleb Rackliffe 
wrote:

> FYI, there is some ongoing sort-of-related work going on in
> CASSANDRA-19534 
>
> On Wed, Apr 10, 2024 at 6:35 PM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Just created an official CEP-41
>> 
>> incorporating the feedback from this discussion. Feel free to let me know
>> if I may have missed some important feedback in this thread that is not
>> captured in the CEP-41.
>>
>> Jaydeep
>>
>> On Thu, Feb 22, 2024 at 11:36 AM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> Thanks, Josh. I will file an official CEP with all the details in a few
>>> days and update this thread with that CEP number.
>>> Thanks a lot everyone for providing valuable insights!
>>>
>>> Jaydeep
>>>
>>> On Thu, Feb 22, 2024 at 9:24 AM Josh McKenzie 
>>> wrote:
>>>
 Do folks think we should file an official CEP and take it there?

 +1 here.

 Synthesizing your gdoc, Caleb's work, and the feedback from this thread
 into a draft seems like a solid next step.

 On Wed, Feb 7, 2024, at 12:31 PM, Jaydeep Chovatia wrote:

 I see a lot of great ideas being discussed or proposed in the past to
 cover the most common rate limiter candidate use cases. Do folks think we
 should file an official CEP and take it there?

 Jaydeep

 On Fri, Feb 2, 2024 at 8:30 AM Caleb Rackliffe <
 calebrackli...@gmail.com> wrote:

 I just remembered the other day that I had done a quick writeup on the
 state of compaction stress-related throttling in the project:


 https://docs.google.com/document/d/1dfTEcKVidRKC1EWu3SO1kE1iVLMdaJ9uY1WMpS3P_hs/edit?usp=sharing

 I'm sure most of it is old news to the people on this thread, but I
 figured I'd post it just in case :)

 On Tue, Jan 30, 2024 at 11:58 AM Josh McKenzie 
 wrote:


 2.) We should make sure the links between the "known" root causes of
 cascading failures and the mechanisms we introduce to avoid them remain
 very strong.

 Seems to me that our historical strategy was to address individual
 known cases one-by-one rather than looking for a more holistic
 load-balancing and load-shedding solution. While the engineer in me likes
 the elegance of a broad, more-inclusive *actual SEDA-like* approach,
 the pragmatist in me wonders how far we think we are today from a stable
 set-point.

 i.e. are we facing a handful of cases where nodes can still get pushed
 over and then cascade that we can surgically address, or are we facing a
 broader lack of back-pressure that rears its head in different domains
 (client -> coordinator, coordinator -> replica, internode with other
 operations, etc) at surprising times and should be considered more
 holistically?

 On Tue, Jan 30, 2024, at 12:31 AM, Caleb Rackliffe wrote:

 I almost forgot CASSANDRA-15817, which introduced
 reject_repair_compaction_threshold, which provides a mechanism to stop
 repairs while compaction is underwater.

 On Jan 26, 2024, at 6:22 PM, Caleb Rackliffe 
 wrote:

 
 Hey all,

 I'm a bit late to the discussion. I see that we've already discussed
 CASSANDRA-15013 
  and CASSANDRA-16663
  at least in
 passing. Having written the latter, I'd be the first to admit it's a crude
 tool, although it's been useful here and there, and provides a couple
 primitives that may be useful for future work. As Scott mentions, while it
 is configurable at runtime, it is not adaptive, although we did
 make configuration easier in CASSANDRA-17423
 . It also is
 global to the node, although we've lightly discussed some ideas around
 making it more granular. (For example, keyspace-based limiting, or limiting
 "domains" tagged by the client in requests, could be interesting.) It also
 does not deal with inter-node traffic, of course.

 Something we've not yet mentioned (that does address internode traffic)
 is CASSANDRA-17324
 , which I
 proposed shortly after working on the native request limiter (and have just
 not had much time to return to). The basic idea is this:

 When a node is struggling under the weight of a compaction backlog and
 becomes a cause of increased read latency for clients, we have two safety
 valves:

[DISCUSS] guardail for global schema modifcations - CASSANDRA-19556 in the context of CASSANDRA-17495

[Štefan Miklošovič]

Hi list,

there is a question in CASSANDRA-19556 we would like to have more feedback
on in order to move forward.

CASSANDRA-19556 wants to introduce two guardrails. One for forbidding /
allowing DCL statements - (Authentication|Authorization)Statement - and
another one
for DDL statements (all schema modifications).

However, there is already a guardrail implemented by CASSANDRA-17495 which
prevents only modifications of schema on a table level so CASSANDRA-19556
might be viewed as a superset of CASSANDRA-17495.

I am not sure why we stopped with tables only in CASSANDRA-17495, this
might be extended to keyspaces too, any schema modification really. I think
we have three options here:

1) drop CASSANDRA-17495 and implement CASSANDRA-19556 which would cover
_all_ schema modifications, not just table-related ones
2) keep CASSANDRA-17495 and implement CASSANDRA-19556 as is currently
proposed - that means that we would be able to forbid all schema
modifications by CASSANDRA-19556 but once schema modifications are allowed,
we might further forbid table modifications as implemented by
CASSANDRA-17495.
3) keep CASSANDRA-17495 but change the implementation of CASSANDRA-19556 in
such a way that it would be more granular. What I mean by the granularity
is that we would have separate guardrail for keyspace, for example.

2) is the least impactful approach but what I do not like is that,
basically, one guardrail (CASSANDRA-19556) would shadow CASSANDRA-17495.
For example, if the first one is disabled but the second one is enabled, we
can modify keyspaces but we can not modify tables. When the first one is
enabled, we can not modify tables even 17495 is not disabled which I find
counterintuitive.

The pros of 3) would be that it would be more granular, indeed, but, is
that even necessary? There are a lot of ddl statements, creation of
triggers, views, indices, functions, aggregates ... How are we going to
categorize it? Do we want to have a guardrail per logical schema component?
Is that not an overkill? Can you come up with a scenario when an operator
wants to disable keyspace modifications but they would enable table
modifications? Or disabling just index, materialized view or function
creations / modifications but e.g keyspace modifications would be possible?
Is it not easier to have one guardrail for all schema modifications?

Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1),
I think that the option 1) is still viable - we would drop CASSANDRA-17495
and we would have CASSANDRA-19556 instead of that which would act as a
global on/off on all schema modifications however given that we go into
beta2 I am not sure if it is not just too late.

Thank you for your opinions in advance.

Regards

Re: [VOTE] Release Apache Cassandra 4.1.5

[Tommy Stendahl via dev]

+1 (nb)

-Original Message-
From: Brandon Williams 
mailto:brandon%20williams%20%3cbrandonwilli...@apache.org%3e>>
Reply-To: dev@cassandra.apache.org
To: dev mailto:dev%20%3c...@cassandra.apache.org%3e>>
Subject: [VOTE] Release Apache Cassandra 4.1.5
Date: Thu, 02 May 2024 11:36:41 -0500


Proposing the test build of Cassandra 4.1.5 for release.


sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a

Git:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Ftree%2F4.1.5-tentative=05%7C02%7Ctommy.stendahl%40ericsson.com%7Ce790102436274c1c68b808dc6ac6180c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502646237162172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Kq7J33gKRiu9MfeoIPIt7C2EsnH%2BMo4K57o%2F4TezPCk%3D=0


Maven Artifacts:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachecassandra-1329%2Forg%2Fapache%2Fcassandra%2Fcassandra-all%2F4.1.5%2F=05%7C02%7Ctommy.stendahl%40ericsson.com%7Ce790102436274c1c68b808dc6ac6180c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502646237170723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=0U8RnCLntXlW%2F%2F34Lf5%2BXWtgGgDVhCiRPIAQbsHDebc%3D=0



The Source and Build Artifacts, and the Debian and RPM packages and

repositories, are available here:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fcassandra%2F4.1.5%2F=05%7C02%7Ctommy.stendahl%40ericsson.com%7Ce790102436274c1c68b808dc6ac6180c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502646237173579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=tK8QrcX8uamHkLFeVcbfL%2FzP0U5Ru1sELvRcp1wLYJc%3D=0



The vote will be open for 72 hours (longer if needed). Everyone who

has tested the build is invited to vote. Votes by PMC members are

considered binding. A vote passes if there are at least three binding

+1s and no -1's.


[1]: CHANGES.txt:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.1.5-tentative%2FCHANGES.txt=05%7C02%7Ctommy.stendahl%40ericsson.com%7Ce790102436274c1c68b808dc6ac6180c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502646237176152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=1isLnjBnNcLbaS19iGJUL7NfY%2FENoE%2BNSm3WVI%2Fuols%3D=0


[2]: NEWS.txt:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.1.5-tentative%2FNEWS.txt=05%7C02%7Ctommy.stendahl%40ericsson.com%7Ce790102436274c1c68b808dc6ac6180c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502646237178682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=jJ9k8JMHtPqw%2BiYT0016irfZAv%2F0JDQk%2FjFK%2BBGBWmE%3D=0

Re: [VOTE] Release Apache Cassandra 4.0.13

[Tommy Stendahl via dev]

+1 (nb)

-Original Message-
From: Brandon Williams 
mailto:brandon%20williams%20%3cdri...@gmail.com%3e>>
Reply-To: dev@cassandra.apache.org
To: dev mailto:dev%20%3c...@cassandra.apache.org%3e>>
Subject: [VOTE] Release Apache Cassandra 4.0.13
Date: Thu, 02 May 2024 10:16:38 -0500


Proposing the test build of Cassandra 4.0.13 for release.


sha1: a6fb3b76feb8467d314b116f937322e1989b42e1

Git:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Ftree%2F4.0.13-tentative=05%7C02%7Ctommy.stendahl%40ericsson.com%7C125fcdc980eb406267c208dc6abaee77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502598299325744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=8G%2FAliqTfaOmOrPQBN3Man0x6oWyMOzDygM6k0rYrmg%3D=0


Maven Artifacts:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachecassandra-1328%2Forg%2Fapache%2Fcassandra%2Fcassandra-all%2F4.0.13%2F=05%7C02%7Ctommy.stendahl%40ericsson.com%7C125fcdc980eb406267c208dc6abaee77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502598299334247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Sp24xWxiev2nwT0CQBu9HlVnvqd28lSRoDkhXd5%2FuPQ%3D=0



The Source and Build Artifacts, and the Debian and RPM packages and

repositories, are available here:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fcassandra%2F4.0.13%2F=05%7C02%7Ctommy.stendahl%40ericsson.com%7C125fcdc980eb406267c208dc6abaee77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502598299337499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=anPCh5rAFANF5XuhVNzcU3x4J7LuyfiHSM%2FJya8ulb8%3D=0



The vote will be open for 72 hours (longer if needed). Everyone who

has tested the build is invited to vote. Votes by PMC members are

considered binding. A vote passes if there are at least three binding

+1s and no -1's.


[1]: CHANGES.txt:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.0.13-tentative%2FCHANGES.txt=05%7C02%7Ctommy.stendahl%40ericsson.com%7C125fcdc980eb406267c208dc6abaee77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502598299340538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=w1CoI3HfrPWS0m4Xqipz71rhgS8l0cYoobxxqmLT%2Fbw%3D=0


[2]: NEWS.txt:



https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.0.13-tentative%2FNEWS.txt=05%7C02%7Ctommy.stendahl%40ericsson.com%7C125fcdc980eb406267c208dc6abaee77%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638502598299345742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=KRESEqsjsMSX2%2FBp6p1arUq06Fzu%2BiyRxwyN%2BtmLKrA%3D=0



Kind Regards,

Brandon