Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

[Doug Rohrer]

Yaman:

Thank you for taking this on - the plan to me looks great, and I'm looking 
forward to seeing it progress.

Doug

> On Jul 2, 2025, at 3:26 PM, Yaman Ziadeh (BLOOMBERG/ 919 3RD A) 
>  wrote:
> 
> Hey everyone!
> 
> Thanks for the great discussion - I've consolidated the discussion points 
> into the following set of requirements:
> Include the async-profiler library with Cassandra
> Allow for easy async-profiler library version upgrades independent of 
> Cassandra
> Expose a JMX interface to access common commands (start, stop, etc.)
> Expose a default-disabled interface to access the 'execute' method for 
> advanced usage
> Create a nodetool command that reaches out to this interface
> Expose this feature through Sidecar's API
> 
> Given these requirements, I'll be developing this feature with the following 
> general plan in mind:
> Drop-in async-profiler jar & native lib files into top-level cassandra repo
> Include these files into the Cassandra build via build.xml
> Make an AsyncProfilerService class for loading native lib file and calling 
> out to the async-profiler.jar
> Register an MBean for the AsyncProfilerService
> MBean provides 3 methods: start, stop, and raw
> "Simple mode": start/stop will allow a common subset of flags (duration, 
> event, output format, etc.)
> raw will expose the execute method for free-use
> default disabled - calls are rejected at runtime unless a JVM flag is 
> included to enable this feature
> Add new `nodetool profile` command
> `nodetool profile start --duration 30 --event cpu`
> `nodetool profile stop `
> `nodetool profile --raw ...`
> Create Sidecar API interface to call out to C* node-specific 
> AsyncProfilerService
> Build a unit/integration test suite for this async-profiler integration in C* 
> and Sidecar

Re: [VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1 (2nd attempt)

[guo Maxwell]

+1

Brandon Williams 于2025年7月9日 周三下午9:50写道：

> +1
>
> Kind Regards,
> Brandon
>
> On Thu, Jul 3, 2025 at 11:07 AM João Reis  wrote:
> >
> > Hey folks,
> >
> > I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release
> (2nd attempt).
> >
> > sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7
> > git:
> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
> >
> > The Source release is available here (r77919):
> >
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/
> >
> > This is the second vote being called for this release after the previous
> vote was stopped due to a critical bug [1] that was found (it's fixed now).
> >
> > 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.
> >
> > Thanks,
> > João
> >
> > [1] https://issues.apache.org/jira/browse/CASSGO-82
> >
>

Re: [VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1 (2nd attempt)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Jul 3, 2025 at 11:07 AM João Reis  wrote:
>
> Hey folks,
>
> I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release (2nd 
> attempt).
>
> sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7
> git: 
> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
>
> The Source release is available here (r77919):
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/
>
> This is the second vote being called for this release after the previous vote 
> was stopped due to a critical bug [1] that was found (it's fixed now).
>
> 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.
>
> Thanks,
> João
>
> [1] https://issues.apache.org/jira/browse/CASSGO-82
>

Re: [DISCUSS] CEP-50: Authentication Negotiation

[Josh McKenzie]

Sorry for the delay in getting to this Joel. This is great work - really well 
thought out and put together. I'm a +1 on it; had the following observations or 
questions reviewing the CEP:

Rather than going with a new discretely allowed option to a closed list of 
allowable options in STARTUP, what if we went the route we did with SUPPORTED 
and offered a variable [string multimap] so we could add future STARTUP options 
w/out fully revving the protocol spec in the future? 
(https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L462-L491)

Any opinion on us deprecating the existing cassandra.yaml#authenticator: option 
to be renamed as "fallback_authenticator", and updating the text to reflect 
that? Or *default_authenticator*; something to denote through the naming that 
the role of that is secondary to the newly added *authenticator_negotiation*? 
I'm 50/50 on this; I don't love deprecation (knowing we're going to keep 
supporting the old nomenclature into perpetuity), but I do think the topic of 
auth is important enough that a little config disruption and maintenance here 
to steer new users to the new, more secure method of auth might warrant the 
change.

> `‘requireAuthentication’ should be set to true as soon as all clients are 
> using other authenticators.`
A hot prop or mutable vtable (... did we ever do mutable / change config 
through vtables? Hm, looks like not yet: 
https://issues.apache.org/jira/browse/CASSANDRA-15254) so we could change this 
live on a cluster w/out bouncing would be nice. Be nicer if that change also 
coincided w/a change in config via 1 UX through the DB. ;) But that's a 
*different* problem than what you're looking to address so worth deferring on 
that piece probably.

re: thundering herd risk - this tickled my memory. We did some work on 
pre-caching things in the Auth cache and I *vaguely recall* getting it into its 
own ThreadPool; I was upstreaming other peoples' code so it's not as durable in 
my memory as usual. https://issues.apache.org/jira/browse/CASSANDRA-16958 and 
https://issues.apache.org/jira/browse/CASSANDRA-16957 come to mind. Ah, there 
we are: https://issues.apache.org/jira/browse/CASSANDRA-17812. We have a 
separate executor specifically for auth messages in Dispatcher.java; might be 
worth keeping an eye on this to see if it proves to be a new bottleneck w/a 
more heavyweight negotiation on connection.

The JIRA link in the CEP just links to the ASF C* JIRA - I couldn't find a 
ticket for this CEP yet in JIRA. Generally we use that to link to a specific 
ticket; was a minor speed bump just FYI.

And we have some prior art in the following:
- CASSANDRA-13048: Support SASL mechanism negotiation in existing Authenticators
- CASSANDRA-11471: Add SASL mechanism negotiation to the native protocol

Might be good to link to those and once we get a JIRA up for CEP-50, we can 
flag those 2 as duplicates of it and close them out once it's done.

Overall - looks great. Again: +1 from me.

On Tue, Jul 8, 2025, at 8:34 PM, Joel Shepherd wrote:
> Hi Doug - That's an interesting suggestion for a load test: I'll include 
> something like that in our plans.
> 
> You're right about the logic in RoleManager: it should be doing the right 
> thing with MutualTlsWithPasswordFallbackAuthenticator.
> 
> Thanks! -- Joel.
> 
> On 7/8/2025 1:52 PM, Doug Rohrer wrote:
>> 
>> +1 from me (I think committer +1s are "binding" on CEPs given our previous 
>> "how we do things" conversation, but either way, +1)...
>> 
>> One interesting perf test to think about would be the difference between 
>> negotiated auth with MutualTlsAuthenticator and PasswordAuthenticator and 
>> the combined MutualTlsWithPasswordFallbackAuthenticator, as I think it'll 
>> provide a pretty good indication of the (hopefully negligible) performance 
>> difference when negotiating.
>> 
>> Also, because I was curious about your last comment... 
>> MutualTlsWithPasswordFallbackAuthenticator _derives_ from 
>> PasswordAuthenticator, so *instanceof PasswordAuthenticator* checks return 
>> *true* for instances of it, and therefore (assuming you're talking about 
>> supportedOptions/alterableOptions in 
>> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L167-L172),
>>  it should work fine. Not that that helps _you_ solve your problem, but at 
>> least the existing classes should work.
>> 
>> Thanks for putting the CEP together and working on the implementation!
>> 
>> Doug
>> 
>>> On Jul 3, 2025, at 2:38 PM, Joel Shepherd  wrote:
>>> 
>>> Thanks Andy - My hope/expectation is this would significantly reduce the 
>>> amount of friction involved when either implementing or migrating to a new 
>>> authenticator. I suspect it will benefit more complex environments too, 
>>> when a single authenticator isn't ideal for all clients.
>>> 
>>> At this point, the stickiest bits I've run into have involved logic that 
>>> switches on "the" authenti

Re: [VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1 (2nd attempt)

[Maxim Muzafarov]

+1

On Wed, 9 Jul 2025 at 16:44, guo Maxwell  wrote:
>
> +1
>
> Brandon Williams 于2025年7月9日 周三下午9:50写道：
>>
>> +1
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Jul 3, 2025 at 11:07 AM João Reis  wrote:
>> >
>> > Hey folks,
>> >
>> > I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release (2nd 
>> > attempt).
>> >
>> > sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7
>> > git: 
>> > https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
>> >
>> > The Source release is available here (r77919):
>> > https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/
>> >
>> > This is the second vote being called for this release after the previous 
>> > vote was stopped due to a critical bug [1] that was found (it's fixed now).
>> >
>> > 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.
>> >
>> > Thanks,
>> > João
>> >
>> > [1] https://issues.apache.org/jira/browse/CASSGO-82
>> >

Re: [VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1 (2nd attempt)

[Jackson Fleming]

+1

On Thu, Jul 10, 2025 at 12:53 AM Maxim Muzafarov  wrote:

> +1
>
> On Wed, 9 Jul 2025 at 16:44, guo Maxwell  wrote:
> >
> > +1
> >
> > Brandon Williams 于2025年7月9日 周三下午9:50写道：
> >>
> >> +1
> >>
> >> Kind Regards,
> >> Brandon
> >>
> >> On Thu, Jul 3, 2025 at 11:07 AM João Reis  wrote:
> >> >
> >> > Hey folks,
> >> >
> >> > I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release
> (2nd attempt).
> >> >
> >> > sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7
> >> > git:
> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
> >> >
> >> > The Source release is available here (r77919):
> >> >
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/
> >> >
> >> > This is the second vote being called for this release after the
> previous vote was stopped due to a critical bug [1] that was found (it's
> fixed now).
> >> >
> >> > 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.
> >> >
> >> > Thanks,
> >> > João
> >> >
> >> > [1] https://issues.apache.org/jira/browse/CASSGO-82
> >> >
>

Re: Sharing a Monthly Cassandra Community Update – Would This Be Useful Here?

[Katona, Amanda via dev]

I find this useful as well.

Another example of this is Last Week in Kubernetes Development | Stay 
up-to-date on Kubernetes development in 15 minutes a week. 
It's useful to always have the overview to stay up to date on conversations, 
merges, and release schedules, but also I do like the shoutout section.

Thanks for taking the lead here!


Amanda Katona

Director of Developer and Open Source Engagement

NetApp Instaclustr



NetApp

619.955.0552 Mobile Phone

akat...@netapp.com



From: Jindal, Himanshu 
Sent: Tuesday, July 8, 2025 4:07 PM
To: dev@cassandra.apache.org 
Subject: Re: Sharing a Monthly Cassandra Community Update – Would This Be 
Useful Here?

You don't often get email from himan...@amazon.com. Learn why this is 
important
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments




Hi Josh,



Thanks for the feedback! I'm happy to break out “#3” into a separate “Dev 
Discussion Summary” thread going forward. I am glad it fits in with the overall 
Community Update.



As for automating with Claude, that’s a great idea. I’ve been using Claude 
mainly to help format the email before sending but a fully automated system 
would be wonderful.



Thanks again for the feedback!



Best,
Himanshu



From: Josh McKenzie 
Reply-To: "dev@cassandra.apache.org" 
Date: Tuesday, July 8, 2025 at 1:02 PM
To: dev 
Subject: RE: [EXTERNAL] Sharing a Monthly Cassandra Community Update – Would 
This Be Useful Here?



CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



Definitely Himanshu! I've had a todo list item for, oh, two? three? months now 
to get to another one of these; I've sent them off and on over the past few 
years. Historically I tried to cover:

  1.  How to get started w/the community
  2.  Releases that have come out
  3.  Any discussions people might want to engage with
  4.  An overview of CI
  5.  And general project velocity (tickets closed out, per release, etc)

If you wanted to break out #3 to a separate email thread like this it'd make it 
a lot easier for me to stay on top of the other 4 items. :)



One thing I've toyed with is the idea of pipelining a summary from Claude on 
email threads from a time frame and potentially JIRA traffic and even visuals 
from 
butler.
 Haven't gotten around to that yet but I feel like there's some real potential 
there.



On Tue, Jul 8, 2025, at 12:47 PM, Jindal, Himanshu wrote:

Hi everyone,

I've been putting together a monthly Cassandra Community Update for my internal 
team. It highlights key conversations from mailing lists and summarizes 
technical discussions that I believe are valuable for anyone following 
Cassandra's evolution.

I’m wondering if folks in the broader community would also find this useful. 
Below is a sample from the May/June timeframe. I’d love your feedback — is this 
something you'd want to receive monthly on this list? If so, I’m happy to start 
sharing future updates here.

Thanks in advance for your thoughts!



Cassandra Community Update – May/June 2025

[Developer List Archive 
Link]

Here’s a quick roundup of recent discussions in the Cassandra community. If 
you're looking to stay informed or contribute, these are great threads to dig 
into — lots of thoughtful technical debate and new ideas this month.







  1.  [DISCUSS] Seeking Guidance on Next Task and Areas to Contribute 
[Link]
A helpful thread full of suggestions for new contributors. If you're looking 
for ways to engage with the Cassandra project, this is must-read.
  2.  A Roadmap to Cassandra Analytics 1.0 
[Link]
This post outlines a vision for evolving Cassandra Analytics from 0.1 to 1.0. 
Lots of actionable suggestions here — great entry points for contributors 
looking to get involved in analytics work.
  3.  [DISCUSS] CEP-48: First-Class Materialized View Support 
[Link

Re: [DISCUSS] CEP-50: Authentication Negotiation

[Joel Shepherd]

Hi Josh - Thanks for all the feedback: appreciate it. Responses to 
specific points interwoven below ...


On 7/9/2025 3:25 AM, Josh McKenzie wrote:


Sorry for the delay in getting to this Joel. This is great work - 
really well thought out and put together. I'm a +1 on it; had the 
following observations or questions reviewing the CEP:


Rather than going with a new discretely allowed option to a closed 
list of allowable options in STARTUP, what if we went the route we did 
with SUPPORTED and offered a variable [string multimap] so we could 
add future STARTUP options w/out fully revving the protocol spec in 
the future? 
(https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L462-L491)


If I'm understanding, you're suggesting making a one-time protocol 
change by adding something like:


  STARTUP: {
   "CQL_VERSION": "3.11",
   
   "OPTIONS":  value>
}

... so that in the future new options could just be keys in the 
multimap, which would not be considered a protocol change? Or placing 
all the options -- current and future -- into the multimap?


I don't have a strong opinion on this. My weak opinion is that -- 
especially if the intent is to put all options in the multimap -- it's 
either going to require careful client-node coordination to roll out the 
protocol change, or it's going to require the node to expect and handle 
both flavors of the STARTUP message structure. Doable but I'm not sure 
that part of the protocol changes so frequently that it's worth the 
effort. I'm not going to argue if you or others have a different and 
stronger opinion on it.


Any opinion on us deprecating the existing 
cassandra.yaml#authenticator: option to be renamed as 
"fallback_authenticator", and updating the text to reflect that? Or 
/default_authenticator/; something to denote through the naming that 
the role of that is secondary to the newly added 
/authenticator_negotiation/? I'm 50/50 on this; I don't love 
deprecation (knowing we're going to keep supporting the old 
nomenclature into perpetuity), but I do think the topic of auth is 
important enough that a little config disruption and maintenance here 
to steer new users to the new, more secure method of auth might 
warrant the change.


I hadn't thought about that but I like the idea. I was striving for 
maximum backwards compatibility, but you're right that the existing key 
could continue to be supported, just not publicized. Going forward, 
something like "default_authenticator" will be less confusing than just 
"authenticator". I'll add it to the doc.


`‘requireAuthentication’ should be set to true as soon as all clients 
are using other authenticators.`
A hot prop or mutable vtable (... did we ever do mutable / change 
config through vtables? Hm, looks like not yet: 
https://issues.apache.org/jira/browse/CASSANDRA-15254) so we could 
change this live on a cluster w/out bouncing would be nice. Be nicer 
if that change also coincided w/a change in config via 1 UX through 
the DB. ;) But that's a /different/ problem than what you're looking 
to address so worth deferring on that piece probably.


Agree it'd be great to be able to enable authn and negotiation without 
having to bounce nodes. Will add.


re: thundering herd risk - this tickled my memory.  We have a 
separate executor specifically for auth messages in Dispatcher.java; 
might be worth keeping an eye on this to see if it proves to be a new 
bottleneck w/a more heavyweight negotiation on connection.


Ah, thanks for pointing that out. I wouldn't expect STARTUP (which is 
where negotiation will actually be resolved server-side) to be 
significantly more expensive than it is today, but will keep an eye on 
that. A second potential bottleneck might lie in the increased overhead 
of the required OPTIONS/SUPPORTED handshake, which I believe today is 
optional: the client can and often does initiate connection with STARTUP 
alone. Again, while I wouldn't expect those to be very expensive to 
handle, offloading them from the requestExecutor might protect the 
workers serving the actual data plane traffic.


The JIRA link in the CEP just links to the ASF C* JIRA - I couldn't 
find a ticket for this CEP yet in JIRA. Generally we use that to link 
to a specific ticket; was a minor speed bump just FYI.


I was deferring creating a JIRA until if/when the CEP was adopted, but 
I'll create one today. Can always close it later.



And we have some prior art in the following:
- CASSANDRA-13048: Support SASL mechanism negotiation in existing 
Authenticators

- CASSANDRA-11471: Add SASL mechanism negotiation to the native protocol

Might be good to link to those and once we get a JIRA up for CEP-50, 
we can flag those 2 as duplicates of it and close them out once it's done.


Great: thanks for the pointers.

One detail where CEP-50 varies a bit from the SASL RFC's description of 
negotiation (https://datatracker.ietf.org/doc/html/rfc4422#section-3.2) 
is that the RFC sugges