Re: [VOTE][IP CLEARANCE] easy-cass-stress

Wanted to bring attention to the question below raised in the incubator list[1] in case it was missed (please reply to gene...@incubator.apache.org ). [1] - https://lists.apache.org/thread/jl69730fl5vns7q4c57lwfsj71ookc4f On Wed, Apr 30, 2025 at 12:40 PM Dave Fisher wrote: > Please note that IP

Re: [VOTE][IP CLEARANCE] easy-cass-stress

es like cassandra-analytics and > cassandra-sidecar. > > > > Jordan > > > > On Wed, Apr 30, 2025 at 09:08 Jon Haddad wrote: > > Id be perfectly fine keeping the name. People do know it, its been around > for two years. > > > > As long as no one

Re: [VOTE][IP CLEARANCE] easy-cass-stress

-incubator (please do not reply this discussion subthread with votes) > This contribution will be placed in a stand-alone repository under the name cassandra-stress Not a big deal, but renaming this project to cassandra-stress could potentially confuse users with legacy (in-tree) cassandra-stress

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

Congratulations Jaydeep! On Wed, 30 Apr 2025 at 07:44 Josh McKenzie wrote: > Hey there Cassandra Devs! > > The Apache Cassandra PMC is very happy to announce that Jaydeep Chovatia > has > accepted the invitation to become a committer! > > Jaydeep has been busy on Cassandra for a good while now,

Re: Welcome David Capwell as Cassandra PMC Member!

Congrats David! On Tue, 29 Apr 2025 at 07:47 Ariel Weisberg wrote: > Huzzah! > > On Mon, Apr 28, 2025, at 3:09 PM, Jon Haddad wrote: > > Hey everyone! > > The Project Management Committee (PMC) for Apache Cassandra is delighted > to announce that David Capwell has joined the PMC! > > Thank you D

Re: [UPDATE] CEP-37

The long awaited feature of managed repairs is finally happening, this is awesome! :) Congrats all for this achievement! On Wed, Apr 23, 2025 at 4:27 PM Jordan West wrote: > Great work all! Another awesome milestone and huge step forward for the > project! > > On Wed, Apr 23, 2025 at 12:47 Jayd

Re: CEP-15 Update

Awesome milestone, congrats and thanks to all involved! 👏👏👏 On Fri, 18 Apr 2025 at 05:19 Dmitry Konstantinov wrote: > Hooray! Huge thanks to all! Now, I have no more excuses — it's time to try > it :-D > > On Thu, 17 Apr 2025 at 23:42, Jordan West wrote: > >> Congrats all! My previous reservati

Re: Project hygiene on old PRs

a JIRA then it could be theoretically closed, even if the PR doesnt have the JIRA# in the PR title, even though I'm not sure this would be desired. On Tue, 15 Apr 2025 at 07:47 Paulo Motta wrote: > Just to clarify option 3), I'm not sure ASF INFRA currently provides the > ability of auto-c

Re: Project hygiene on old PRs

t GitHub takes the top line of the commit message which we explicitly >> say shouldn’t contain the JIRA (that goes in the second line). Until we >> have a solution it’s reasonable to ask folks to make that manual change but >> we should also accept folks will forget or won’t do it be

Last week to submit Cassandra proposals to Community Over Code 2025

Hi, I wanted to send a gentle reminder that the deadline for submissions to Community Over Code 2025 closes in 1 week at 23:59 UTC on April 21, 2025. Please submit your proposal via https://sessionize.com/community-over-code-na-2025 Thanks to all who have submitted so far. Feel free to reach out

Re: Project hygiene on old PRs

*committers (and not reviewers) On Mon, Apr 14, 2025 at 12:13 PM Paulo Motta wrote: > > I am not sure why it is so hard for people to not forget to close a PR > when their branch is merged. > > I wonder if reviewers* know they need to append the message "Closes > #P

Re: Project hygiene on old PRs

> I am not sure why it is so hard for people to not forget to close a PR when their branch is merged. I wonder if reviewers know they need to append the message "Closes #PR_ID" to the end of the commit message to have the PR be closed, this does not seem very obvious, but it's also a bit inconven

Happy Friday!

Hi, I wanted to send a gentle reminder that the deadline for submissions to Community Over Code closes in 1 month on 23:59 UTC on April 21, 2025. Please submit your proposal via https://sessionize.com/community-over-code-na-2025 The best moment to start working on your proposal is today. It is be

Re: Huge NetApp donation of hardware for ci-cassandra

As an exclusive user of ci-cassandra.a.o I'm very grateful for this donation. 🙏 I never got circle-ci to work on my machine 🥲😉 Thanks all for making this happen! On Wed, 19 Mar 2025 at 12:51 Mick Semb Wever wrote: > > Under a ASF targeted sponsorship, NetApp (Instaclustr) has been very > gener

Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

. > PMC members, please check carefully the IP Clearance requirements before > voting. > > The vote will be open for 72 hours (or longer). Votes by PMC members > are considered binding. A vote passes if there are at least three > binding +1s and no -1's. +1

Fwd: [CFP] Community Over Code NA 2025

Hi, Please see message below with instructions on submitting talk proposals for Community Over Code 2025. *The deadline for submissions is April 21st 2025.* Please note there is usually no deadline extension for this conference, so I'd highly recommend submitting your proposals on time. You can

Re: [RELEASE] Apache Cassandra Sidecar 0.1.0 released

Damn.. listing name sucks. Also Saranya and whoever else was involved in this epic milestone! Taking the occasion, happy international women's day to all Cassandrettes 🌹 On Sat, 8 Mar 2025 at 11:24 Paulo Motta wrote: > Congrats on this release! 🍾👏👏 Awesome work to all involved, s

Re: [RELEASE] Apache Cassandra Sidecar 0.1.0 released

Congrats on this release! 🍾👏👏 Awesome work to all involved, specially but not limited to Dinesh, Francisco, Bernado et al 😊 On Fri, 7 Mar 2025 at 16:48 Patrick McFadin wrote: > We happen to have some very informed engineers discussing Sidecar and > the many things you can do with it at Cassandra

Welcome Ekaterina Dimitrova as Cassandra PMC member

Aloha, The Project Management Committee (PMC) for Apache Cassandra is delighted to announce that Ekaterina Dimitrova has joined the PMC! Thanks a lot, Ekaterina, for everything you have done for the project all these years. The PMC - Project Management Committee - manages and guides the directio

Community Over Code Asia Travel Assistance Applications now open!

Hi, The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code Asia 2025 are now open! We will be supporting Community over Code Asia, Beijing, China July 25th to the 27th 2025. TAC exists to help those that would like to attend Com

Re: Welcome Bernardo Botella as Cassandra Committer

¡Felicitaciones Bernardo! Well deserved! Cheers, Paulo On Tue, 4 Mar 2025 at 06:10 Soheil Rahsaz wrote: > Congrats, Bernardo! Well deserved! 🎉 Looking forward to seeing your > continued impact on the project. > > > On Tue, Mar 4, 2025 at 12:03 PM Dmitry Konstantinov > wrote: > >> Congrats Ber

Re: Welcome Aaron Ploetz as Cassandra Committer

Congratulations Aaron, happy to see you recognized as a committer! Cheers, Paulo On Tue, 4 Mar 2025 at 03:26 Bernardo Botella wrote: > That’s awesome!! > > Congratulations Aaron!! Long overdue for sure! > > > On Mon, Mar 3, 2025 at 16:25 Patrick McFadin wrote: > >> The Apache Cassandra PMC is

Re: Welcome Caleb Rackliffe to the PMC

Congrats on this long overdue nomination! 🥃 :-) On Sun, 2 Mar 2025 at 06:31 Mike Adamson wrote: > Congratulations Caleb! > > On Fri, 28 Feb 2025, 19:11 Doug Rohrer, wrote: > >> Congrats Caleb! >> >> On Feb 26, 2025, at 10:14 PM, Jordan West wrote: >> >> Congrats Caleb!! >> >> Jordan >> On Wed

Re: New committers: Maxwell Guo and Dmitry Konstantinov

Congratulations Maxwell and Dmitry, well deserved! On Thu, Feb 20, 2025 at 3:20 PM Aaron wrote: > Congratulations Maxwell and Dmitry! That's awesome! > > On Thu, Feb 20, 2025 at 1:12 PM Maxim Muzafarov wrote: > >> Congratulations! >> >> On Thu, 20 Feb 2025 at 19:17, Abe Ratnofsky wrote: >> > >

Reviewer needed: CASSANDRA-11303 New inbound throughput parameters for streaming

Hi, Would anyone have cycles and be kind enough to review Runtian's patch for CASSANDRA-11303 ? I think this could be a nice addition if not already added by some other ticket. Cheers, Paulo

Re: Welcome Jeremiah Jordan to the PMC

Congrats JD! On Fri, 14 Feb 2025 at 18:35 guo Maxwell wrote: > Congrats！ > Tolbert, Andy 于2025年2月15日 周六上午6:22写道： > >> Congrats JD! >> >> On Fri, Feb 14, 2025 at 4:13 PM wrote: >> >>> Congratulations, well deserved! >>> >>> El 14 feb 2025, a las 20:40, Alex Petrov escribió: >>> >>>  >>> Congra

Re: Merging compaction improvements to 5.0

gt;> On Wed, Feb 12, 2025 at 4:26 PM guo Maxwell >>> wrote: >>> >>>> I think it should be tested on most cloud platforms（at least >>>> aws、azure、gcp） before merged into 5.0 . Just like CASSANDRA-19488. >>>> >>>> Paulo Mo

Re: Merging compaction improvements to 5.0

an opportunity to demonstrate what I think is the > level of detail that a patch like this should have, so I hope you get a > chance to take the time to check out the JIRA. There's 100x more detail > there than I've provided in this email. > > Jon > > > On Wed,

Re: Merging compaction improvements to 5.0

I'm looking forward to these improvements, compaction needs tlc. :-) A couple of questions: Has this been tested only on EBS, or also EC2/bare-metal/Azure/etc? My only concern is if this is an optimization for EBS that can be a deoptimization for other environments. Are there reproducible scripts

Re: Meaningless emptiness and filtering

On Tue, Feb 11, 2025 at 5:00 PM Patrick McFadin wrote: > > You get my vote for the best subject line I've seen this week. > +1, I'm deeply saddened that despite this title this post does not contain the answer to the ultimate question of life, the universe, and everything. :-( > On Tue, Feb 11,

CVE-2025-26467: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions (4.0.16 only)

Severity: moderate Affected versions: - Apache Cassandra 4.0.16 Description: Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to

Re: CVE-2025-23015: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions

/yprngr9cmp9c43m1c56thv1v0v6y5ywq [2] - https://lists.apache.org/thread/hc9shwlm1kmxdxosbh3qo2xooqoo3sc6 On Mon, Feb 3, 2025 at 6:19 PM Paulo Motta wrote: > > Severity: moderate > > Affected versions: > > - Apache Cassandra 3.0.0 through 3.0.30 > - Apache Cassandra 3.1.0 through 3.11.17 > - Apache

CVE-2025-24860: Apache Cassandra: CassandraNetworkAuthorizer and CassandraCIDRAuthorizer can be bypassed allowing access to different network regions

+dev@cassandra.apache.org -- Forwarded message - From: Paulo Motta Date: Mon, Feb 3, 2025 at 6:20 PM Subject: CVE-2025-24860: Apache Cassandra: CassandraNetworkAuthorizer and CassandraCIDRAuthorizer can be bypassed allowing access to different network regions To: , Severity

CVE-2025-23015: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions

+dev@cassandra.apache.org -- Forwarded message - From: Paulo Motta Date: Mon, Feb 3, 2025 at 6:19 PM Subject: CVE-2025-23015: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions To: , Severity: moderate

Re: [VOTE] Release Apache Cassandra 5.0.3

+1 tested docker image build (verify binary gpg+sha512sum) + jre17 single node startup Verification steps/output: ``` $ docker build -t apache/cassandra-test:5.0.3 --build-arg CASSANDRA_VERSION=5.0.3 --build-arg CASSANDRA_SHA512=9b2fa89f729a89473934a18d4056d200859bed6e4f9d288b9fca9e8f4056c2d1ccb

Re: [VOTE] Release Apache Cassandra 4.1.8

+1 tested docker image build (verify binary gpg+sha512sum) + jre11 single node startup Verification steps/output: ``` $ docker build -t apache/cassandra-test:4.1.8 --build-arg CASSANDRA_VERSION=4.1.8 --build-arg CASSANDRA_SHA512=13eee692627b5c88b2e6cda56e0aa1e5605403a777514f541496fa1985decb9b941

Re: [VOTE] Release Apache Cassandra 4.0.16

+1 tested docker image build (verify binary gpg+sha512sum) + jre11 startup Verification steps/output below (sorry mck was not able to check https://github.com/apache/cassandra-builds/pull/32 yet so went with my poor man's verification) ``` $ docker build -t apache/cassandra-test:4.0.16 --build-a

Re: Capabilities

ou can’t write > more than X bytes, when this is outside of TCM accord can have multiple > different values while executing the query (assuming a user changed it)… > > > On Jan 29, 2025, at 11:04 AM, Paulo Motta wrote: > > > Using TCM to distribute this information acro

Re: Capabilities

t; On Fri, Dec 20, 2024 at 7:42 PM Štefan Miklošovič > wrote: > > I am super hesitant to base distributed guardrails or any configuration > for that matter on anything but TCM. Does not "C" in TCM stand for > "configuration" anyway? So rename it to TSM like "

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

d satisfy the check. Makes sense, I think this would be good to have as a lint or test to easily catch overlooks during review. On Fri, Jan 24, 2025 at 9:44 AM Štefan Miklošovič wrote: > > > On Fri, Jan 24, 2025 at 3:27 PM Paulo Motta wrote: > >> > from time to time I se

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

> from time to time I see configuration properties in Config.java and they are clearly not in cassandra.yaml. Not every property in Config is in cassandra.yaml. I would like to know if there is some specific reason behind that. I think one of the original reasons was to "hide" advanced configs tha

Re: What branches should perf fixes be targeting

Thanks for starting this discussion Jordan. Even though I'm not familiar with the specific changes proposed by CASSANDRA-15452, see my comments on generally allowing performance improvements to old branches. > I believe they should target every active branch because performance is a major selling

Re: [Committer/reviewer needed] Request for Review of Cassandra PRs

Thanks for this message Runtian. I realized I was previously assigned as reviewer for CASSANDRA−11303 but I will not be able to review it at this time. There's also CASSANDRA-19248 that is waiting for review in case someone has cycles to review it. Reviewing community patches is a great way to l

Re: Capabilities

ions in case of guardrails which flip some booleans and > numbers would suddenly make TCM way more complex? Come on ... > > This has nothing to do with what Jordan is trying to introduce. I think we > all agree he knows what he is doing and if he evaluates that TCM is too > mu

Re: Capabilities

> It should be possible to use distributed system tables just fine for capabilities, config and guardrails. I have been thinking about this recently and I agree we should be wary about introducing new TCM states and create additional complexity that can be serviced by existing data dissemination m

Re: Capabilities

Nice stuff! I support this proposal and would be happy to help on this. On Wed, Dec 18, 2024 at 6:00 PM Jordan West wrote: > In a recent discussion on the pains of upgrading one topic that came up is > a feature that Riak had called Capabilities [1]. A major pain with upgrades > is that each nod

Re: Supporting 2.2 -> 5.0 upgrades

I think that will not > happen until we are out of Ant as doing this multi jar / subproject mumbo > jumbo is not too much appealing to ... anybody? > > ________ > From: Paulo Motta > Sent: Thursday, December 12, 2024 17:35 > To: dev@cassandra.apac

Re: Supporting 2.2 -> 5.0 upgrades

> +1 on moving the read/write logic into its own jar. +1, not only read-write logic but anything used by both the server and subprojects (ie. cassandra-sidecar), for example JMX Mbeans and other interfaces. I think one way to do that would be to split cassandra-all into cassandra-server and cass

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

e time or keep them well demarcated. > > On 12 Dec 2024, at 15:04, Paulo Motta wrote: > >  > > > If we don’t intend to begin fixing the feature within the next year or > so we should deprecate it entirely. > > +1 - this is probably topic for another thread but isn’t MVs funda

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

These are all things we kind of do implicitly and ad-hoc on the mailing > list, and I'm not looking to tie us down to any granular structure or > specificity. More thinking it could be useful for someone that's worked on > something who wonders "Huh. How do I take this from b

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Strong evidence to indicate superiority in majority of workloads (by >count or importance or size, etc) > > These are all things we kind of do implicitly and ad-hoc on the mailing > list, and I'm not looking to tie us down to any granular structure or > specificity. More t

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Thanks for bringing up this topic, Josh. Outside of the major features (ie. MV/SAI/TCM/Accord), one related discussion in this topic is: how can we "promote" small improvements in existing features from optional to default ? It makes sense to have optimizations launched behind a feature flag init

Re: [DISCUSS] 5.1 should be 6.0

I share this sentiment. Outside of marketing and API compatibility considerations, I think the changes are significant enough to warrant a major version bump, since it represents a new generation of the database. On Tue, Dec 10, 2024 at 1:02 PM Brandon Williams wrote: > Even if TCM is api-compat

Re: Re-evaluate compaction defaults in 5.1/trunk

scussions going > at once? > > On Sun, Dec 8, 2024 at 8:44 AM Paulo Motta wrote: > >> >> Hi Dave, >> >> I appreciate these performance/cost considerations and I believe these >> should be taken into account when evaluating default changes. >> &g

Re: Re-evaluate compaction defaults in 5.1/trunk

t >> percentage of Cassandra tables across all clusters currently in operation >> are 2:1 read-to-write or more? >> >> If the answer is a solid majority, I think this would justify the default >> change. >> >> -Dave >> >> David A. Herrington II

Re: Re-evaluate compaction defaults in 5.1/trunk

ult and operators could disable the new default via a flag. This would be done whether we change to LCS now, or to UCS later. On Sun, 8 Dec 2024 at 08:43 Paulo Motta wrote: > Hi Dave, > > I'm also in the field and my experience is different. > > I have seen new users shooting

Re: Re-evaluate compaction defaults in 5.1/trunk

Hi Dave, I'm also in the field and my experience is different. I have seen new users shooting themselves in the foot with the default compaction strategy STCS on a regular basis over the past few years and have been recommending them to switch to LCS and they no longer encounter issues after maki

Re: Re-evaluate compaction defaults in 5.1/trunk

Hi Jon, Thanks for your perspective on this topic, that's helpful feedback! I understand the default compaction strategy choice depends on multiple deployment and workload factors. How about this to allow Cassandra to be more flexible for different workload types: Update CQL with: CREATE TABLE

Re: Re-evaluate compaction defaults in 5.1/trunk

has been over-used and has lost all > meaning. How is Java 17 experimental? Very confusing for the community. > > I think TWCS should use UCS under the hood which would address streaming > performance (and thus node density) or UCS could be updated to allow for > time window's options

Re-evaluate compaction defaults in 5.1/trunk

Hi, It’s 2024 and users are still facing issues due to misconfigured compaction when using default configuration. I would like to start a conversation around improving compaction defaults in 5.1/trunk, so users trying out CQL transactions don’t need to worry about tuning compaction. A few sugges

Re: [DISCUSS] Modeling JIRA fix version for subprojects

+1 to Mick’s suggestion CASS-DRIVER- / CASS-SIDECAR / CASS-ANALYTICS, this feels more consistent and readable than without the dash. Also -1 to CASSANA fwiw, sorry Stefan 😅 /bikeshed On Fri, 18 Oct 2024 at 05:55 Mick Semb Wever wrote: > Could we also rename CASSANDRASC to CASSSIDECAR ? > > And

Re: CEP-15: Accord status

Thanks all for the work on this epic! Is there an implementation summary guide similar to guide_8099.md [1] that can help reviewers not involved with the effort navigate through the code ? It would be great to have it if this is not already available or being planned. There's a similar one though

Re: Call for Volunteers: Community Over Code North America 2024

oops, actually meant by tomorrow eod anywhere (Fri, Aug/30). 😄 Cheers, Paulo On Thu, 29 Aug 2024 at 20:06 Paulo Motta wrote: > Friendly reminder: please submit your proposal by tomorrow (08/29) end of > day if you are planning to attend and would like to contribute to an > Apache

Re: Call for Volunteers: Community Over Code North America 2024

Feel free to reach out to me or #cassandra-comdev on ASF slack[2] if you have any suggestions or ideas. Cheers, Paulo [1] - https://www.apachecon.com/acna19/bof.html [2] - https://the-asf.slack.com/ On Wed, Aug 21, 2024 at 10:46 AM Paulo Motta wrote: > Hi, > > I would like to invite

Call for Volunteers: Community Over Code North America 2024

Hi, I would like to invite Cassandra contributors and enthusiasts to gather in Denver, USA from October 7 to 10 for the ASF conference Community Over Code (formerly known as ApacheCon). There will be two days of Cassandra talks on Monday (10/07) and Tuesday (10/08). You can check the event schedu

Re: Welcome Joey Lynch as Cassandra PMC member

Congratulations Joey! On Thu, 25 Jul 2024 at 00:55 Venkata Hari Krishna Nukala < n.v.harikrishna.apa...@gmail.com> wrote: > Congratulations Joey!! > > On Thu, 25 Jul 2024 at 7:20 AM, Joseph Lynch > wrote: > >> Thank you all for the warm wishes and I greatly appreciate this >> opportunity! >> >>

Re: Cassandra PMC Chair Rotation, 2024 Edition

Thank you Josh and congratulations Dinesh! On Thu, 20 Jun 2024 at 11:52 Josh McKenzie wrote: > Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra > Project Management Committee (PMC) I would like to welcome and congratulate > our next PMC Chair Dinesh Joshi (djoshi). > > Di

Re: [VOTE] CEP-24 Password validation / generation

+1 On Mon, Jun 17, 2024 at 5:32 AM Štefan Miklošovič wrote: > Hi everyone, > > I would like to start the voting for CEP-24 as all feedback in the > discussion threads seem to be addressed. > > Proposal: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146 > JIRA under whi

Re: [DISCUSS] ccm as a subproject

As much as I'd like to remove the dependency on ccm I think we'll stick with it for a bit, so +1 on moving under the project umbrella. In the long term it would be nice to modernize integration test suites to use containers instead of processes for more flexibility and fewer dependencies for local

Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

Congratulations Alexandre, Andy, Bret and Olivier! :-) On Wed, Apr 17, 2024 at 1:11 PM Benjamin Lerer wrote: > The Apache Cassandra PMC is pleased to announce that Alexandre Dutra, > Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the > invitation to become committers on the jav

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

I am sympathetic to having a native fast instance migration solution as this is a common operational recipe. > It's valuable for Cassandra to have an ecosystem-native mechanism of migrating data between physical/virtual instances outside the standard streaming path. As Hari mentions, the current

Re: Update: C/C NA Call for Presentations Deadline Extended to April 15th

19 PM Paulo Motta wrote: > Hi, > > I wanted to update that the Call for Presentations deadline was extended > by two weeks to April 15th, 2024 for Community Over Code North America > 2024. Find more information on this blog post: > https://news.apache.org/foundation/entry/apa

Update: C/C NA Call for Presentations Deadline Extended to April 15th

Hi, I wanted to update that the Call for Presentations deadline was extended by two weeks to April 15th, 2024 for Community Over Code North America 2024. Find more information on this blog post: https://news.apache.org/foundation/entry/apache-software-foundation-opens-cfp-for-community-over-code-n

Two weeks remaining to submit abstracts to Community Over Code 2024

Hi, I'd like to send a friendly reminder that the deadline for submissions to Community Over Code North America 2024 ends in two weeks on April 1st, 2024. This conference will be held in Denver, Colorado, October 7-10, 2024. We're looking for abstracts in the following areas: * Customizing and t

Call for Presentations: Cassandra @ Community Over Code North America 2024

Hi, After a successful experience in ApacheCon 2022, the Cassandra track is back to Community Over Code North America 2024 to be held in Denver, Colorado, October 7-10, 2024. I will be facilitating this track and I would like to request abstract drafts in the following topics to be presented in t

Re: [Discuss] Repair inside C*

ss as TCM/Accord primitives become available and mature. On Thu, Feb 22, 2024 at 1:44 PM Paulo Motta wrote: > +1 to Josh's points, The project has considered native repair scheduling > for a long time but it was never made a reality due to the complex > considerations involved and ava

Re: [Discuss] Repair inside C*

+1 to Josh's points, The project has considered native repair scheduling for a long time but it was never made a reality due to the complex considerations involved and availability of custom implementations/tools like cassandra-reaper, which is a popular way of scheduling repairs in Cassandra. Un

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

vnodes/no-vnodes, offheap/onheap, and nothing about >> other stuff. To me running no-vnodes makes no sense because no-vnodes is >> just a special case of vnodes=1. On the other hand offheap/onheap buffers >> could be tested in unit tests. In short, I'd run dtests only with t

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> It's also been questioned about why we don't just enable settings we recommend. These are settings we recommend for new clusters. *Our existing cassandra.yaml needs to be tailored for existing clusters being upgraded, where we are very conservative about changing defaults.* I think this unnece

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> Perhaps it is also a good opportunity to distinguish subsets of tests which make sense to run with a configuration matrix. Agree. I think we should define a “standard/golden” configuration for each branch and minimally require precommit tests for that configuration. Assignees and reviewers can d

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> If there’s an “old compatible default” and “latest recommended settings”, when does the value in “old compatible default” get updated? Never? How about replacing cassandra.yaml with cassandra_latest.yaml on trunk when cutting cassandra-6.0 branch? Any new default changes on trunk go to cassandra

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

I share Jacek’s and Stefan’s sentiment about the low value of requiring precommit j11+j17 tests for all changes. Perhaps this was needed during j17 stabilization but is no longer required? Please correct if I’m missing some context. To have a practical proposal to address this, how about: 1) Def

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

Cool stuff! This will make it easier to advance configuration defaults without affecting stable configuration. Wording looks good to me. +1 to include a NEWS.txt note. I'm ok with breaking trunk CI temporarily as long as failures are tracked and triaged/addressed before the next release. I haven'

Re: [VOTE] Release Apache Cassandra 4.1.4

+1 Reviewed changelog + tested docker image build (verify binary gpg+sha512sum) + jre11 startup. On Tue, Feb 6, 2024 at 4:03 PM Brandon Williams wrote: > I think we lost track of this one over some concern about > CASSANDRA-19097, but that turned out to be a test problem. +1 > > Kind Regards,

Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

Thanks for the links. Checked the latest ci-cassandra 4.1 runs [1][2][3] and looks like the only consistently flaky across these runs is MemtableSizeTest being tracked on CASSANDRA-17298 so I think we're good to go. [1] https://ci-cassandra.apache.org/job/Cassandra-4.1/461/ [2] https://ci-cassandr

Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

Is there a CI test run of this release candidate tag available ? Fwiw, docker image build (verify binary gpg+sha512sum) + jre11 startup looks good with: CASSANDRA_VERSION=4.1.4;docker build -t apache/cassandra-test:$CASSANDRA_VERSION --build-arg CASSANDRA_VERSION=$CASSANDRA_VERSION --build-arg C

Fwd: [Important] GSoC 2024 Project Ideas

See details below for submitting project ideas for GSoC 2024. This is a good opportunity to attract/mentor new contributors. I am not planning to mentor a project this year but would be happy to offer support if someone wants to submit a proposal. Please message me if you are interested or have an

Re: [VOTE] Release Apache Cassandra 4.0.12

DRA_SHA512=65de9cc32f3d22d55f5c7c3b1417285a41aabb70fa8a4ae8d9d85a58e644f43151bf4f386cc45773b6ac317db38c4576b139ca6b6fcdbbd16993d09ee2a5c2b8 https://github.com/pauloricardomg/docker-cassandra.git#:4.0 $ sudo docker run apache/cassandra-test:4.0.12 -f On Mon, Jan 22, 2024 at 11:08 PM Paulo Motta wrote: > +1 > > Tested docker image bui

Re: [VOTE] Release Apache Cassandra 4.0.12

+1 Tested docker image build (binary+checksum+signature) and container startup with: $ docker build --build-arg CASSANDRA_VERSION=4.0.12 --build-arg CASSANDRA_SHA512=65de9cc32f3d22d55f5c7c3b1417285a41aabb70fa8a4ae8d9d85a58e644f43151bf4f386cc45773b6ac317db38c4576b139ca6b6fcdbbd16993d09ee2a5c2b8 ht

Re: Welcome Maxim Muzafarov as Cassandra Committer

Congratulations Maxim! On Tue, Jan 9, 2024 at 10:16 AM Benjamin Lerer wrote: > I am always late to the party. ;-) > Congrats Maxim! > > Le mar. 9 janv. 2024 à 13:16, Maxim Muzafarov a > écrit : > >> Thank you all so much, I'm happy to be part of such an active >> community and to be able to co

Call for Presentations closing soon: Community over Code EU 2024

I wanted to remind that the call for speakers for Community Over Code EU 2024 (formerly Apachecon EU) will be closing this Friday 2024/01/12 23:59:59 GMT. If you reside in Europe/EMEA and have an interesting talk proposal about using, deploying or modifying Apache Cassandra please see details belo

Re: Future direction for the row cache and OHC implementation

I like Dinesh's middle ground proposal, since this feature has valid uses. I'm not familiar with the row caching module, but would it make sense to take this opportunity to expose this feature as an optional Row Caching Module, disabled by default with an optional on-heap Caffeine implementation?

Fwd: Reminder: CFP for Community Over Code Europe is now open

There will be a Cassandra track at Community Over Code Europe 2024 (formerly known as Apachecon EU) that will happen on Bratislava, Slovakia on 3 Jun 2024. If you have any talks proposals about using, deploying or modifying Apache Cassandra please make a submission before 12 Jan 2024 to speak at a

Re: [VOTE] Release Apache Cassandra 5.0-beta1

y a PMC via binding -1 Opinions supporting the proposal are also valuable, provided there are no valid claims against a proposal. On Wed, 29 Nov 2023 at 22:27 Paulo Motta wrote: > To me, the goal of a beta is to find unknown bugs. If no new bugs are > found during a beta release, then

Re: [VOTE] Release Apache Cassandra 5.0-beta1

To me, the goal of a beta is to find unknown bugs. If no new bugs are found during a beta release, then it can be automatically promoted to RC via re-tagging. Likewise, if no new bugs are found during a RC after X time, then it can be promoted to final. If we end up not releasing a final 5.0 artif

Re: [DISCUSS] Update default disk_access_mode to mmap_index_only on 5.0

change in 5.0? If not, we will merge in 24 hours. Thanks, Paulo [1] - https://lists.apache.org/thread/w0gkdj7fhylycqwmd73p0kfck7jr8qth [2] - https://issues.apache.org/jira/browse/CASSANDRA-19021 On Wed, Sep 6, 2023 at 5:12 PM Paulo Motta wrote: > > I wonder why disk_access_mode property is

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

Nice, thanks for the quick fix! Checked and working now. On Sat, 4 Nov 2023 at 21:11 Mick Semb Wever wrote: > > > On Sun, 5 Nov 2023 at 00:49, Paulo Motta wrote: > >> > With the publication of this release I would like to switch the >> default 'latest'

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> With the publication of this release I would like to switch the default 'latest' docs on the website from 4.1 to 5.0. Are there any objections to this ? It looks like the switch of latest to 5.0 broken some top search links (returns 404 to me): [1] - https://www.google.com/search?q=apache+cas

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

urse. Also, we need a bit >> more investigation here. I can try to take a look tomorrow in more >> detail if no one beats me to that. >> >> Best regards, >> Ekaterina >> >> >> On Fri, 3 Nov 2023 at 20:01, Paulo Motta wrote: >> >

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

Clarification: - When running nodetool only the "Unknown module" warnings show up. All warnings show up during startup. On Fri, Nov 3, 2023 at 7:58 PM Paulo Motta wrote: > Launched a tarball-based 5.0-alpha2 container on top of > "eclipse-temurin:17-jre-focal" and the

  1   2   3   >