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

I’m working on updating the date in the form. Some feedback I plan to eventually give: it took me literally 12 hours (that’s not an exaggeration) to clone the ASF Infra repo (on a good internet connection) to make this one line change and that took the free time I had over the weekend for this. To

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

I’m generally supportive. The concept is one that I can see the benefits of and I also think the current implementation adds a lot of complexity to the codebase for being stuck in experimental mode. It will be great to have a more robust version built on a better approach. On Sun, May 4, 2025 at 0

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

+1 to docker. It’s a relatively universal dependency at this point, allows for more repeatable builds, and doesn’t require installing software in the build. It’s not any more heavyweight that go or python and has less environment nuances. It lets us pick what python (or go) we use among many other

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

Congratulations!! Well deserved On Wed, Apr 30, 2025 at 18:44 jay.zhuang.yahoo.com via dev < dev@cassandra.apache.org> wrote: > Congratulations Jaydeep [image: Emoji] > > On Wednesday, April 30, 2025 at 10:04:42 AM PDT, Runtian Liu < > curly...@gmail.com> wrote: > > > congratulations! > > On Wed,

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

t;> +1 (nb) >> >> >> >> -- >> >> *From:* Jon Haddad >> >> *Sent:* Wednesday, April 30, 2025 8:24:44 AM >> >> *To:* dev@cassandra.apache.org >> >> *Cc:* gene...@incubator.apache.org >> >&g

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

Jordan West wrote: > I will defer to Mick on the proposed naming, and any requirements, as that > came from the document he created that is linked at the start of the > thread. I don’t have a personal preference besides to note that it conforms > with all the other project names li

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

ming this project to cassandra-stress could >> potentially confuse users with legacy (in-tree) cassandra-stress, since >> this is the name referred to in old documentation. Not sure what would be a >> more appropriate name though, just keep easy-cass-stress perhaps? >>

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

+1 On Wed, Apr 30, 2025 at 8:15 AM Jordan West wrote: > (general@incubator cc'd) > > Please vote on the acceptance of the easy-cass-stress (to be renamed > cassandra-stress) and its IP Clearance: > > https://incubator.apache.org/ip-clearance/cassandra-easy-cass-stress.ht

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

(general@incubator cc'd) Please vote on the acceptance of the easy-cass-stress (to be renamed cassandra-stress) and its IP Clearance: https://incubator.apache.org/ip-clearance/cassandra-easy-cass-stress.html All consent from original authors of the donation, and tracking of collected CLAs, is fo

Re: Welcome David Capwell as Cassandra PMC Member!

Congratulations!!! On Mon, Apr 28, 2025 at 2:43 PM David Capwell wrote: > Thanks everyone =) > > On Apr 28, 2025, at 2:13 PM, Bernardo Botella < > conta...@bernardobotella.com> wrote: > > Oh wow that’s awesome David!! > > Congratulations!! > > On Apr 28, 2025, at 1:09 PM, Pavel Yaskevich wrote:

Re: [VOTE] Simplifying our release versioning process

precate, technically. >> I agree with this. I think the JVM version the server runs under and how >> we cycle those is a separate discussion from feature deprecation. >> >> There can and has been some overlap there that would need to be handled >> on a case by case b

Re: [VOTE] Simplifying our release versioning process

I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not. Regarding JVM version what I’ve mo

Re: Python and Go callouts during ant compile/build task

Should we consider making that the default and then passing false explicitly in CI/builds? I agree with Alex it’s a bit surprising and shorter build times when developing would be helpful. Jordan On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever wrote: > Python and Go are used by the gen-doc target

Re: [UPDATE] CEP-37

Great work all! Another awesome milestone and huge step forward for the project! On Wed, Apr 23, 2025 at 12:47 Jaydeep Chovatia wrote: > The CEP-37 work has been successfully merged into the trunk today! Please > let me know if you have any issues. > > This merge is a massive win for Apache Cass

Re: Merging compaction improvements to 5.0

/apache/cassandra/commit/17cb89208c804680ffd4445d6a826171a67edb79 Jordan On Mon, Apr 14, 2025 at 5:00 AM Chris Lohfink wrote: > +1 > > On Sun, Apr 13, 2025 at 12:32 PM Jordan West wrote: > >> Hi Folks, >> >> A bit delayed but I have the backport for 20092 ready. T

Re: CEP-15 Update

the community to removing this work would be >>> very high. But, I do not intend to argue Accord’s case here. I will let you >>> all decide. >>> >>> Please decide soon though, as it shapes our work planning. The positive >>> reception so far had lead me t

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 12:14 Jeremiah Jordan wrote: > +1 > > On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie > wrote: > >> [DISCUSS] thread: >> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq >> >> The proposed new versioning mechanism: >> >>1. We no longer use semver .MI

Re: Project hygiene on old PRs

If we want something to happen repeatably we should automate it not add more manual tasks to the list. Paulo’s suggestion seems to be in line with that so +1 to something in that direction. We continually are swimming upstream making up our own process. The ask to put the ticket number in the PR

Re: Merging compaction improvements to 5.0

's less of a nice to have and more > of a "some cluster falls over periodically now". > > Ariel > > On Fri, Feb 14, 2025, at 5:23 PM, Jordan West wrote: > > Thanks for the write up Mick. I think its is a great evaluation of 15452. > A few notes below: > >

Re: [DISCUSS] 5.1 should be 6.0

I don’t think there is any world where we can justify such major changes being called 5.1. 5.0 had significantly less major changes. Mick, the topics you bring up are important. But I don’t think they are required for the community to decide we are calling this 6.0. We’ve tried that approach and we

Re: [DISCUSS] 5.1 should be 6.0

I am +1 on 6.0 as well. The other topics brought up on this thread are important, and we should address them, but I think we can move forward with the version decision in parallel. Jordan On Thu, Apr 10, 2025 at 11:50 AM Brad wrote: > > . I assume JDK 21 may lead to removal of JDK 11 which is b

Re: CEP-15 Update

ma w nodes down issue > and anything written on it? > Yes, there is a clear known path for fixing schema changes, and gladly > they do not require a protocol change, just a slightly deeper integration > with TCM. > > > On Fri, Mar 7, 2025, at 4:44 PM, Jordan West wrote: >

Re: [UPDATE] CEP-37

Thank you for the update Jaydeep. Very excited to see the progress here. I’m removed the internal status of our deployment of it now but from the JIRAs, meetings, and other conversations my impression is this feature has been heavily tested and is production grade. Jordan On Fri, Mar 7, 2025 at 1

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I too initially felt we should just use mounts and was excited by e.g. Single Zone Express mounting. As Cheng mentioned we tried it…and the results were disappointing (except for use cases who could sometimes tolerate seconds of p99 latency. That brought me around to needing an implementation we ow

Re: CEP-15 Update

ge imbalance of over-investment to recoup, and anything >> unnecessary will be deferred. >> >> Since the feature is disabled, and the code is almost entirely isolated, >> I cannot imagine the cost to the community to removing this work would be >> very high. But, I do

Re: CEP-15 Update

ugh, as it shapes our work planning. The positive > reception so far had lead me to consider prioritising a move to trunk-first > development within the next week or two, and the associated work that > entails. However, if that was optimistic we will have to shift our plans. > > >

Re: CEP-15 Update

ll let you >> all decide. >> >> Please decide soon though, as it shapes our work planning. The positive >> reception so far had lead me to consider prioritising a move to trunk-first >> development within the next week or two, and the associated work that >> en

Re: CEP-15 Update

The work and effort in accord has been amazing. And I’m sure it sets a new standard for code quality and correctness testing which I’m also entirely behind. I also trust the folks working on it want to take it to the a fully production ready solution. But I’m worried about circumstances out of our

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congratulations!!! On Wed, Mar 5, 2025 at 07:01 Abe Ratnofsky wrote: > Congratulations Ekaterina! 🎉 >

Re: Welcome Aaron Ploetz as Cassandra Committer

Congratulations!! On Tue, Mar 4, 2025 at 09:57 Tolbert, Andy wrote: > Congrats Aaron! > > On Tue, Mar 4, 2025 at 11:24 AM Francisco Guerrero > wrote: > >> Congratulations Aaron! >> >> On 2025/03/04 00:23:49 Patrick McFadin wrote: >> > The Apache Cassandra PMC is very happy to announce that Aaron

Re: Welcome Bernardo Botella as Cassandra Committer

Congratulations!! On Tue, Mar 4, 2025 at 10:16 Arjun Ashok wrote: > Congratulations Bernardo !! > > On Mon, Mar 3, 2025 at 11:31 PM Štefan Miklošovič > wrote: > >> The Project Management Committee (PMC) for Apache Cassandra has invited >> Bernardo Botella to become a committer and we are please

Re: Welcome Caleb Rackliffe to the PMC

Congrats Caleb!! Jordan On Wed, Feb 26, 2025 at 13:01 Mick Semb Wever wrote: > . > >> >> Please join us in welcoming Caleb to his new role! >> > > > > Congratulations Caleb !! > >

Re: Welcome Caleb Rackliffe to the PMC

Congrats Caleb!! Jordan On Thu, Feb 20, 2025 at 18:13 Bernardo Botella wrote: > So many good news today! Congratulations Caleb! > > > > On Feb 20, 2025, at 4:07 PM, Ekaterina Dimitrova > wrote: > > That’s awesome addition! Well done! Thanks for everything, Caleb!! > Congrats!!! > > On Thu, 20

Re: New committers: Maxwell Guo and Dmitry Konstantinov

Congrats both! Looking forward to working with you more in the future. Jordan On Thu, Feb 20, 2025 at 14:20 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, Ab

Re: Merging compaction improvements to 5.0

Thanks for the write up Mick. I think its is a great evaluation of 15452. A few notes below: * CI links for 15452 might be burried and I may need to link the most recent run (I’ve been using CircleCI since it’s what I’m familiar with — happy to have runs on ASf hardware as well). * 15452 is confi

Re: Welcome Jeremiah Jordan to the PMC

Congrats, JD! Welcome aboard! Jordan On Fri, Feb 14, 2025 at 11:01 Mick Semb Wever wrote: >. > > > I hope you will join me in welcoming him to the committee. > > > Welcome JD! >

Re: Merging compaction improvements to 5.0

disk access patterns during compaction and range > reads (PR available) https://github.com/apache/cassandra/pull/3606 > > Thanks, > > – Scott > > On Feb 12, 2025, at 9:45 PM, guo Maxwell wrote: > > > Of course, I definitely hope to see it merged into 5.0.x as

Re: Merging compaction improvements to 5.0

Regarding the buffer size, it is configurable. My personal take is that we’ve tested this on a variety of hardware (from laptops to large instance sizes) already, as well as a few different disk configs (it’s also been run internally, in test, at a few places) and that it has been reviewed by four

Re: [DISCUSS] 5.1 should be 6.0

Mick, There is a lot to respond to here and I think we might need a few other threads to avoid a spidering conversation but I wanted to respond to what I saw is at least part of the crux of your concern: our recommended upgrade paths. To take a snippet from your email "A little empathy for our use

Patrick McFadin joins the PMC

The PMC's members are pleased to announce that Patrick McFadin has accepted an invitation to become a PMC member. Thanks a lot, Patrick, for everything you have done for the project all these years. Congratulations and welcome!! The Apache Cassandra PMC

Re: What branches should perf fixes be targeting

come up between community members and I wanted to bring it to the broader mailing list is all. On Tue, Jan 21, 2025 at 6:35 PM Jordan West wrote: > Thanks for the initial feedback. I hear a couple different themes / POVs. > > David/Paulo, it sounds like maybe a guide for perf ba

Re: What branches should perf fixes be targeting

ing deep in the storage engine to be 1% faster is not worth the risk, > because most users will skip the type of qualification that finds those one > in a billion regressions. > > Patch releases are for bug fixes not perf improvements. > > > On Jan 21, 2025, at 9:10 PM, Jord

What branches should perf fixes be targeting

Hi folks, A topic that’s come up recently is what branches are valid targets for performance improvements. Should they only go into trunk? This has come up in the context of BTI improvements, Dmitry’s work on reducing object overhead, and my work on CASSANDRA-15452. We currently have guidelines p

Re: [DISCUSS] Bracing style on trunk

While on the surface I would like to change the rules going forward, the special or hybrid rules sound like a nightmare for lingers. I’m -1 unless the change comes with functional changes to e.g. the idea files etc. if someone wants to take that on I’m all for modernizing the style guide. Jordan

Re: [DISCUSS] Review Guide for the project

I generally support a guide we can point new contributors to as well. Jordan On Sat, Jan 18, 2025 at 10:20 Dinesh Joshi wrote: > As a growing community with new committers and contributors, I would > support establishing a review guide to ensure consistency and uniformity of > feedback. > > On

Re: Checkstyle as style contract for Cassandra

I too had the same experience as Jon (not with Go but with a project that had a pre-commit linter and another that did it in IntelliJ — much nicer than the pre-commit formatter). If we have a guide it should be as automatable as possible. I feel strongly about that. From the responses I also think

Re: Checkstyle as style contract for Cassandra

during reviews. > > On Thu, Jan 16, 2025 at 8:44 PM Jordan West wrote: > >> IMO the more we can enforce the style guide programmatically the better. >> It was a big improvement when we got parts of it in IntelliJ. It saves time >> and reduces friction. The burden shouldn

Re: Checkstyle as style contract for Cassandra

IMO the more we can enforce the style guide programmatically the better. It was a big improvement when we got parts of it in IntelliJ. It saves time and reduces friction. The burden shouldn’t be on humans to place or check that every curly brace is on its own line. And if we say don’t check during

Re: EmbeddedCassandraService - still supported?

Setting up IntelliJ, running Cassandra and cqlsh/nodetool locally, and using the debugger is also a great way to familiarize Jordan On Tue, Jan 14, 2025 at 17:11 Brandon Williams wrote: > I've sent a slack invite to your email. The embedded service is no longer > around, perhaps try the docker

Re: Capabilities

places we > risk this the better IMO. > > Of course, there are steps we could take to expose a limited API targeting > these use cases, as well as using a separate log for ancillary > functionality, that might better balance risk:reward. But equally I’m not > sure it makes se

Re: Capabilities

ttle bit of a pushback (1) >>>>> (even though super reasonable one) that TCM is just too young at the >>>>> moment >>>>> and it would be desirable to go through some stabilisation period. >>>>> >>>>> Another idea was that we should

Re: Capabilities

One minor clarification: ETS is entirely in memory (unless you explicitly dump it to disk or use DETS) so the equivalence to a local system table is only partially accurate but I think the parallel is fine in the case of what I was describing. Jordan On Fri, Dec 20, 2024 at 09:07 Jordan West

Re: Capabilities

Capabilities are built on TCM and I wanted to do Guardrails on TCM too >> but was explained it is probably too soon, I guess you would experience >> something similar. >> >> Sam's comment is from May and maybe a lot has changed since in then and >> his comment i

Re: Capabilities

ndividual node configures itself > in some way or not to comply? > > Is there any intersection in these approaches? At first sight it seems > somehow related. How is one different from another from your point of view? > > Regards > > (1) https://issues.apache.org/jira/browse/CAS

Capabilities

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 node independently decides when to start using new or modified functionality. Even when we put this behind a config (like storage compa

Re: Default sorting in nodetool status CASSANDRA-20104

I think it’s good we have a yaml/json option but don’t think that rules out having sorting when not using that output type. Jordan On Fri, Dec 13, 2024 at 15:26 Abe Ratnofsky wrote: > Looks like we’re moving towards supporting JSON output for nodetool > commands: > > CASSANDRA-12698

Re: Default sorting in nodetool status CASSANDRA-20104

I don’t have a strong preference. I agree with Chris that for those clusters not using vnodes, by token is nice. Not sure if it’s worth having the branching for that or just pick some other default and let people use the sort flags to sort by token when applicable. Jordan On Fri, Dec 13, 2024 at

Path to UCS being default our compaction strategy

Splitting this out from the other thread. It seems like there is broad support for eventually moving towards UCS as our default compaction strategy. What do we think needs to be completed ahead of that change. What I've heard so far: * Time / more reports of use in production - In particular for m

Re: Re-evaluate compaction defaults in 5.1/trunk

While we continue the discussion here on short term defaults do we all feel it would be beneficial to start a new thread on what is required to get UCS over the line as a default? So we can have both discussions going at once? On Sun, Dec 8, 2024 at 8:44 AM Paulo Motta wrote: > > Hi Dave, > > I

Re: Re-evaluate compaction defaults in 5.1/trunk

tless. > > The main grievances over UCS all seem to be doc related, and a lack of > experience. These are both fixable problems. > > Jon > > > > > On Sat, Dec 7, 2024 at 9:48 AM Jordan West wrote: > >> Generally agree with the following sentiments: >> >>

Re: Re-evaluate compaction defaults in 5.1/trunk

Generally agree with the following sentiments: - LCS as the stable default, it’s not perfect and can blow up but it’s the best in the majority of cases. All of the compaction strategies come with foot guns of varying sizes. If STCS is replaced by UCS it definitely should not be the default. - mov

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Wed, Nov 6, 2024 at 11:15 Chris Lohfink wrote: > +1 > > On Wed, Nov 6, 2024 at 11:10 AM Francisco Guerrero > wrote: > >> +1 (nb) >> >> On 2024/11/06 14:07:47 "Tolbert, Andy" wrote: >> > +1 (nb) >> > >> > On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie >> wrote: >> > >> > > +1 >> > > >> > >

Re: [DISCUSS] Donating easy-cass-stress to the project

Josh/Mick, where does that leave us? I’d like to start with the smaller scope Josh described in his last email. We can tackle in-tree/stress separately. I was going to start working on getting signed ICLAs. Does that still sound like the right next step? Or is that also not necessary unless we tak

Re: [Discuss] Repair inside C*

Agreed with the sentiment that decomposition is a good target but out of scope here. I’m personally excited to see an in-tree repair scheduler and am supportive of the approach shared here. Jordan On Tue, Oct 22, 2024 at 08:12 Dinesh Joshi wrote: > Decomposing Cassandra may be architecturally d

Re: [DISCUSS] Donating easy-cass-stress to the project

should also start releasing >> Cassandra this way to make it easier for OSX users to install locally, but >> that's a separate discussion. >> >> Jon >> >> >> On Wed, Oct 9, 2024 at 11:48 AM Jordan West wrote: >> >>> Count me in as a cont

Re: [DISCUSS] Donating easy-cass-stress to the project

 > Hi folks, > > I'm familiar with the codebase and can help with the maintenance and > evolution. > I already have some additional profiles that I can push there which were > never merged in the main branch of tlp-cluster. > > I love this tool (I know I'm

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Agreed this would absolutely be a win. Dont see need for a flag either. On Tue, Oct 1, 2024 at 1:31 PM Caleb Rackliffe wrote: > Alrighty, with what looks like a fair amount of support, I'll declare > CASSANDRA-19968 ready > for some prelimi

Re: [VOTE] Release Apache Cassandra 4.1.7

+1. Validated by starting and creating a 3 node cluster using easy-cass-lab. Jordan On Fri, Sep 20, 2024 at 7:36 AM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.1.7 for release. > > sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a > Git: https://github.com/apache/cassandra/t

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

ss (avoid workload and utilization imbalances) > > All three points are achievable with very straightforward approaches that > will not require much operator involvement. > > I guess my main point is we need to solve load balancing (summarized by > the above three points) before we start

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

+1 to Benedict’s (and others) comments on plugability and low overhead when disabled. The latter I think needs little justification. The reason I am big on the former is, in my opinion: decisions on approach need to be settled with numbers not anecdotes or past experience (including my own). So I w

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It sounds like a replacement is not really practical so I'll ignore that option for now, until a viable alternative is proposed. I am -1 on us writing our own without strong, strong justification -- primarily because I think the

Re: Welcome Chris Bannister, James Hartig, Jackson Flemming and João Reis, as cassandra-gocql-driver committers

Congrats, welcome! On Thu, Sep 12, 2024 at 13:16 Dinesh Joshi wrote: > Congratulations, everyone! > > On Thu, Sep 12, 2024 at 4:40 AM Mick Semb Wever wrote: > >> The PMC's members are pleased to announce that Chris Bannister, James >> Hartig, Jackson Flemming and João Reis have accepted invitat

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

gt;> simply be alerting the operator to something that has already gone very >> wrong that they may not be in any position to ever address. >> >> On Sep 12, 2024, at 12:44 PM, Jordan West wrote: >> >>  >> I’m +1 on enabling rejection by default on all branches

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

I think folks not losing sleep over this are only in that position because they don’t know it’s happening. Like Brandon said, ignorance is bliss (but it’s a false bliss). Very few users do the work necessary to detect data loss outside the obvious paths. I agree with Caleb, if we log and give them

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

I’m +1 on enabling rejection by default on all branches. We have been bit by silent data loss (due to other bugs like the schema issues in 4.1) from lack of rejection on several occasions and short of writing extremely specialized tooling its unrecoverable. While both lack of availability and data

Re: 【DISCUSS】The configuration of Commitlog archiving

+1 to Scott’s comments. Once you expose those YAML config params outside of a single node which many of us do, this becomes an RCE attack vector. Something more structured as Scott proposes, similar to snapshots, would be preferred. Would recommend a CEP. Jordan On Fri, Aug 30, 2024 at 20:58 C. S

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

Thanks all!!! On Sat, Aug 31, 2024 at 07:55 J. D. Jordan wrote: > Two great additions to the PMC. Congratulations to you both! > > -Jeremiah Jordan > > > On Aug 30, 2024, at 3:21 PM, Jon Haddad wrote: > > > >  > > The PMC's members are please

Re: Welcome Doug Rohrer as Cassandra Committer

Awesome! Congratulations Doug! On Fri, Aug 23, 2024 at 12:17 Štefan Miklošovič wrote: > Great news! Congratulations, Doug. > > On Fri, Aug 23, 2024 at 8:55 PM Dinesh Joshi wrote: > >> The Apache Cassandra PMC is thrilled to announce that Doug Rohrer has >> accepted the invitation to become a co

Re: [VOTE] Release Apache Cassandra 5.0-rc2

+1, validated again with easy-cass-lab On Thu, Aug 22, 2024 at 6:48 AM Mick Semb Wever wrote: > . > > > 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 l

Re: [VOTE] Release Apache Cassandra 4.1.6 - take 2

+1 btw, I validated the tarball release super quickly using easy-cass-lab ( https://github.com/rustyrazorblade/easy-cass-lab). Steps I took: 1. modified cassandra_versions.yaml to point the 4.1 version at the new release tarball of 4.1.6 2. built the image: bin/easy-cass-lab build-image (got a cof

Re: [DISCUSS] inotify for detection of manually removed snapshots

I lean towards the documentation approach vs complicating the implementation. For me personally: I regularly use shell commands to operate on snapshots. That includes listing them. I probably should use nodetool for it all instead though. Jordan On Fri, Aug 9, 2024 at 08:09 Štefan Miklošovič wr

Re: [DISCUSS] state of lz4-java

Oof this is a tough one. I agree with both of you on the concerns. I don’t have good answers but I do see a few options: - upgrade to 1.10.0 (optionally and w rigorous testing ofc) and then start to think of a deprecation plan for LZ4 in project. That would be unfortunate but we could probably do

Re: [DISCUSS] Removing support for deterministic table IDs

point of creation. I'd liken it to what we did w/ some > no-longer-relevant options for the batch commit log. > > On Tue, Jul 30, 2024 at 5:19 PM Jordan West wrote: > >> Generally no disagreement but more of a curiosity: what’s the motivation >> for removal? Just that it’s

Re: [DISCUSS] Removing support for deterministic table IDs

Generally no disagreement but more of a curiosity: what’s the motivation for removal? Just that it’s not needed? Otherwise it’s relatively cheap and DDL aren’t high throughput (or at least shouldn’t be since we can only deal with so many tables) Jordan On Tue, Jul 30, 2024 at 15:04 Caleb Rackliff

Re: [VOTE] Release Apache Cassandra 4.1.6

I would make the case that loss of availability / significant performance issue, regardless of the amount of time it has existed for, is worth fixing on the branches that are widely deployed by the community. Especially when weighed against a loosely defined public interface issue. The queuing iss

Re: [VOTE] Release Apache Cassandra 4.1.6

If there is a quick fix for the interface issue as Alex is describing then I am all for it. I think binary compatibility isn’t required here so the compile time compat would be good enough. Otherwise I tend to agree that while it should be considered a public interface we haven’t had a strict defi

Re: Welcome Joey Lynch as Cassandra PMC member

Congrats Joey! Jordan On Fri, Jul 26, 2024 at 09:22 Maxim Muzafarov wrote: > My congratulations Joseph Lynch! > > On Thu, 25 Jul 2024 at 18:15, Paulo Motta wrote: > > > > Congratulations Joey! > > > > On Thu, 25 Jul 2024 at 00:55 Venkata Hari Krishna Nukala < > n.v.harikrishna.apa...@gmail.com

Re: [VOTE] CEP-42: Constraints Framework

+1 On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero wrote: > +1 > > On 2024/07/02 18:45:33 Josh McKenzie wrote: > > +1 > > > > On Tue, Jul 2, 2024, at 1:18 PM, Abe Ratnofsky wrote: > > > +1 (nb) > > > > > >> On Jul 2, 2024, at 12:15 PM, Yifan Cai wrote: > > >> > > >> +1 on CEP-42. > > >> > > >>

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

+1 On Fri, Jun 28, 2024 at 05:56 wrote: > +1 > > > On Jun 27, 2024, at 3:03 PM, Josh McKenzie wrote: > > +1 > > On Thu, Jun 27, 2024, at 12:40 AM, Abhijeet Dubey wrote: > > +1 > > On Thu, Jun 27, 2024 at 1:47 AM Francisco Guerrero > wrote: > > +1 > > On 2024/06/21 15:13:31 Venkata Hari Krishna

Re: [DISCUSS] CEP-42: Constraints Framework

I am generally for this CEP, particularly the sizeOf guardrail. For example, we recently had an incident caused by a client who wrote outside of the contract we had verbally established. The constraint would have let us encode that contract into the database. In this case, clients are writing large

Re: [DISCUSS] Stream Pipelines on hot paths

Agreed Aleksey. I wouldn’t be opposed to more nuanced use but the burden that adds seems impractical. A simple rule is easier. Jordan On Fri, Jun 7, 2024 at 05:59 Aleksey Yeshchenko wrote: > It am okay with its use off hot paths in principle, and I’ve done it > myself. > > But as others have me

Re: [DISCUSS] Stream Pipelines on hot paths

Similarly in the "don't use them in the main project but am ok with tests" camp On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič < stefan.mikloso...@gmail.com> wrote: > I have created > > https://issues.apache.org/jira/browse/CASSANDRA-19673 > > to gather all your ideas about what to remove. If y

Re: [DISCUSS] ccm as a subproject

I would also love to see CCM as an official side project. It is important to the project and I personally use it regularly. Jordan On Thu, May 16, 2024 at 7:55 AM Josh McKenzie wrote: > We do still have the issues of DSE-supporting code in it, as we do with > the drivers. I doubt any of us str

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

On Wed, May 1, 2024 at 3:34 AM Alex Petrov wrote: > > We can implement CEP-40 using a similar approach: we can leave the source > node as both a read and write target, and allow the new node to be a target > for (pending) writes. Unfortunately, this does not help with availability > (in fact, it

Re: [DISCUSS] Gossip Protocol Change

I’m a big +1 on 18917 or more testing of gossip. While I appreciate that it makes TCM more complicated, gossip and schema propagation bugs have been the source of our two worst data loss events in the last 3 years. Data loss should immediately cause us to evaluate what we can do better. We will li

Re: [DISCUSS] Donating easy-cass-stress to the project

I would likely commit to it as well Jordan On Mon, Apr 29, 2024 at 10:55 David Capwell wrote: > So: besides Jon, who in the community expects/desires to maintain this > going forward? > > > I have been maintaining a fork for years, so don’t mind helping maintain > this project. > > On Apr 28, 2

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

I do really like the framing of replacing a node is restoring a node and then kicking off a replace. That is effectively what we do internally. I also agree we should be able to do data movement well both internal to Cassandra and externally for a variety of reasons. We’ve seen great performance

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

If we are considering the main process then we have to do some additional work to ensure that it doesn’t put pressure on the JVM and introduce latency. That’s one thing I like about having it an external process — not that it’s bullet proof but it’s one less thing to worry about. Jordan On Thu, A

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

Thanks for proposing this CEP! We have something like this internally so I have some familiarity with the approach and the challenges. After reading the CEP a couple things come to mind: 1. I would like to see more abstraction of how the files get moved / put in place with the proposed solution be

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

I would also like to back this proposal. We change this default because several incidents have occurred by leaving the default of auto. There are rare cases where auto/mmap is the better option but as for a default mmap_index_only is safer. On Wed, Nov 15, 2023 at 6:35 AM Paulo Motta wrote: > Hi

  1   2   >