Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection

I like the idea of adding this to the CQL Grammar, but would like to see it follow the ReplicationStrategy style of defining a map with a class and parameters. For example, something like this (names I’m not tied to): SELECT * FROM table WHERE pk = x WITH ARTIFICIAL LATENCY = { 'class': 'Unifor

Re: CEP-15 multi key transaction syntax

The new syntax looks great, and I’m really excited to see this coming together. One piece of feedback on the proposed syntax is around the use of “=“ as a declaration in addition to its current use as an equality operator in a WHERE clause and an assignment operator in an UPDATE: BEGIN TRANSACT

[DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Hello all, We currently depend on Maven Ant Tasks (MAT) during build, for declaring dependencies and generating POM files from within build.xml. MAT has long been retired (no commits since maintenance in 2015), has registered CVEs in its dependencies (CVE-2017-1000487), and encourages migration

Re: [DISCUSS] CASSANDRA-17750: Security migration away from Maven Ant Tasks

Most of the discussion has happened in the PR: https://github.com/apache/cassandra/pull/1725 Leaving this thread open over the weekend to gather input. > On Jul 20, 2022, at 10:40 AM, emmanuel warreng > wrote: > > Unsubscribe > > On Tue, Jul 19, 2022, 21:20 Abe Ra

Re: [DISCUSS] CEP-23: Enhancement for Sparse Data Serialization

Looking at this link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-23%3A++Enhancement+for+Sparse+Data+Serialization Do you have any plans to include benchmarks in your test plan? It would be useful to include disk usage / read performance / write performance comparisons with the ne

Re: Using bash instead of sh in generate.sh?

I took a look through our scripts, and Bash is used in a handful of development tools. /bin/sh is used by everything under bin/ and tools/bin. I wouldn’t want to change a user-facing dependency unless there’s a solid reason, but I think it’s fine for CircleCI tooling to use Bash instead of /bin/

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Could we defer the close of this vote til Monday, December 12th after 6pm Pacific Time? Jon Meredith and I have been working thru an issue blocking streaming on 4.1 for the last couple months, and are now testing a promising fix. We're currently working on a write-up, and we'd like to hold the

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

Sorry - responded on the take1 thread: Could we defer the close of this vote til Monday, December 12th after 6pm Pacific Time? Jon Meredith and I have been working thru an issue blocking streaming on 4.1 for the last couple months, and are now testing a promising fix. We're currently working o

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

in the repro). And I’d >> personally be a bit surprised if table count matters that much. >> >> It probably just requires high core count and enough data that the streams >> actually interact with the rate limiter >> >>> On Dec 11, 2022, at 10:32 AM,

[DISCUSS] CEP-22: Drivers Donation Status

What's the current status of CEP-22? It looks like the CEP draft on Confluence [1] hasn't been updated since Aug 2022 and mailing list search [2] shows no results, so it never made it to a vote. -- Abe [1]: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-22%3A+Datastax+Drivers+Donat

Re: Downgradability

Some interesting existing work on this subject is "Understanding and Detecting Software Upgrade Failures in Distributed Systems" - https://dl.acm.org/doi/10.1145/3477132.3483577, also summarized by Andrey Satarin here: https://asatarin.github.io/talks/2022-09-upgrade-failures-in-distributed-sys

Re: [DISCUSS] Enhanced Disk Error Handling

Thanks for proposing this discussion Bowen. I see a few different issues here: 1. How do we safely handle corruption of a handful of tokens without taking an entire instance offline for re-bootstrap? This includes refusal to serve read requests for the corrupted token(s), and correct repair of t

Re: [DISCUSS] Enhanced Disk Error Handling

hat are currently being > rejected by replicas with a mechanism to kick off a repair of those ranges > could be interesting. > > On Thu, Mar 9, 2023, at 1:45 PM, Abe Ratnofsky wrote: >> Thanks for proposing this discussion Bowen. I see a few different issues >> here:

Re: [DISCUSS] Enhanced Disk Error Handling

e's > no immediately obvious "Correct" answer to where that point is regardless of > what mechanism we're using to hold a cluster-wide view of topology. > >> ...CEP-21 makes this sequencing safe... > For sure - I wouldn't advocate for any kind of "

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

I agree with Bowen - I find Keyspace easier to communicate with. There are plenty of situations where the use of "database" is ambiguous (like "Could you help me connect to database x?"), but Keyspace refers to a single thing. I think more software is moving towards calling these things "namespa

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

Just to make sure I'm understanding the details, this would mean apache/cassandra-harry maintains its status as a separate repository, apache/cassandra references it as a submodule, and clones and builds Harry locally, rather than pulling a released JAR. We can then reference Harry as a library

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

gt;>>>>>>>>> - which stymies development due to the friction. >>>>>>>>>> This is my major concern. >>>>>>>>>> >>>>>>>>>> What prompted this thread was harry being external to the

Re: [DISCUSS] CEP-8 Drivers Donation - take 2

Sharing the same sentiment. Thank you for all your efforts on getting this ready to contribute! > On May 26, 2023, at 9:59 AM, Francisco Guerrero wrote: > > I second Dinesh's sentiment. I'm looking forward to this contribution. > > On 2023/05/26 16:29:12 Dinesh Joshi wrote: >> This is exciting

Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 (nb)On Jun 13, 2023, at 09:23, Andrés de la Peña wrote:+1On Tue, 13 Jun 2023 at 16:40, Yifan Cai wrote: +1 From: David Capwell Sent: Tuesday, June 13, 2023 8:37:10 AM To: dev Subject: Re: [VOTE] CEP-8 Datastax Dri

Re: [VOTE] CEP 33 - CIDR filtering authorizer

+1 (nb)On Jun 28, 2023, at 18:38, guo Maxwell wrote:+1 Nate McCall 于2023年6月29日 周四上午9:25写道：+1 On Wed, Jun 28, 2023 at 5:17 AM Shailaja Koppu wrote:Hi Team,(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to follow usual procedure).Pleas

Re: [DISCUSS] Using ACCP or tc-native by default

This feels analogous to other past discussions around prioritizing a config that enables new users to clone + build + run as easily as possible, vs. having better prod recommendations out of the box. Both are important. I personally think we should default configuration to make it just work for

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1 (nb) > On Jul 21, 2023, at 3:03 PM, Jon Meredith wrote: > > +1 > > On Fri, Jul 21, 2023 at 2:33 PM Blake Eggleston > wrote: >> +1 >> >>> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa >> > wrote: >>> >>> Hi Everyone! >>> >>> I wou

Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

I think it would be good for the project to have an official PyPI distribution, and the signal from users (40K downloads per month) is a clear indication that this is useful. Timely releases would help us get future improvements to cqlsh out faster, and moving this to an official distribution wo

[DISCUSS] CASSANDRA-18743 Deprecation of metrics-reporter-config

Hey folks, Opening a thread to get input on a proposed dependency deprecation in 5.0: metrics-reporter-config has been archived for 3 years and not updated in nearly 6 years. This project has a minor security issue with its usage of unsafe YAML loading via snakeyaml’s unprotected Constructor:

Re: [DISCUSS] CASSANDRA-18743 Deprecation of metrics-reporter-config

t;> “ The rationale for this proposed deprecation is that the upcoming 5.0 >>>> release is a good time to evaluate dependencies that are no longer >>>> receiving updates and will become risks in the future.” >>>> >>>> Thank you for raising it, I

Re: [DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

If we're going to do bulk dependency pruning, we should minimize the number of deprecation plans that users need to prepare for. There will likely be a few more dependencies we clean up around 5.0, so sticking with 5.0 deprecation and 6.0 removal for all of them would likely make our users' live

Re: [DISCUSSION] Dependency management in our first alpha release

> I also want to hear if Abe still has concerns about not following deprecation > process here. I support removing the library on an expedited schedule, rather than waiting for a full major of deprecation. We still have a large surface for metrics integrations, and users who depended on metrics

Re: Development Dependencies documentation.

Following back up here - patch has been updated and is ready for review: https://github.com/apache/cassandra-website/pull/170 > On Oct 25, 2023, at 8:07 AM, Ekaterina Dimitrova > wrote: > > Hi Claude, > You are not wrong. Unfortunately, it is outdated. Abe Ratnofsky has a work

Re: [DISCUSS] Harry in-tree

Another strong +1 to have Harry in-tree, and another +1 to building shaded dtest JARs on release. There are a number of projects that would benefit from having these JARs available in a central repository, like Sidecar, Driver, etc. I didn't see a ticket so created one: https://issues.apache.or

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

Congrats Francisco! > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas wrote: > > Congratulations, Francisco! > > - Scott > >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi wrote: >> >> The PMC members are pleased to announce that Francisco Guerrero Hernandez >> has accepted >> the invitation to

[DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

Hey folks - wanted to raise a separate thread to discuss publishing of dtest-shaded JARs on release. Currently, adjacent projects that want to use the jvm-dtest framework need to build the shaded JARs themselves. This is a decent amount of work, and is duplicated across each project. This is ma

Re: [DISCUSSION] CEP-38: CQL Management API

Adding to Hari's comments: > Any changes expected at client/driver side? While using JMX/nodetool, it is > clear that the command/operations are getting executed against which > Cassandra node. But a client can connect to multiple hosts and trigger > queries, then how can it ensure that command

Re: Welcome Maxim Muzafarov as Cassandra Committer

Congrats Maxim! > On Jan 8, 2024, at 1:28 PM, Ekaterina Dimitrova wrote: > > Congrats, Maxim! Well deserved! Thank you for everything! > > On Mon, 8 Jan 2024 at 13:26, Jeremiah Jordan > wrote: >> Congrats Maxim! Thanks for all of your contributions! >> >> On

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

Hardware acceleration for more things would be great, especially based on the success of ACCP (CASSANDRA-18624 ). But I think it would be ideal to use existing compressor names and use hardware acceleration if a given JAR is present on the

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

What is the audience for dual-native-port operation? My understanding is that most users can use a single port for optional SSL, ever since CASSANDRA-10559 . Using a single port for both encrypted and unencrypted traffic also makes clients m

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

CASSANDRA-9590 (Support for both encrypted and unencrypted native transport connections) was implemented before CASSANDRA-10559 (Support encrypted and plain traffic on the same port), but both been available since 3.0. On 9590, STARTTLS was considered, but rejected due to the changes that would

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

> For existing versions what about having a “default ssl” or “default no SSL” > yaml setting which decides what port is advertised? Then someone could still > connect on the other port manually specifying. Then new column can be added > with the new table in trunk. I'm assuming "advertisement

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

> Deprecating helps nothing for existing releases. We can’t/shouldn’t remove > the feature in existing releases. The deprecation I'm proposing is intended to push people to configure their servers in a way that is more secure and maximizes compatibility with clients. Deprecating can help for ex

Re: [Discuss] Introducing Flexible Authentication in Cassandra via Feature Flag

Hey Guarav, Thanks for your proposal. > disruptive, full-cluster restart, posing significant risks in live > environments For configuration that isn't hot-reloadable, like providing a new IAuthenticator implementation, a rolling restart is required. But rolling restarts are zero-downtime and

[DISCUSS] Fixing coverage reports for jvm-dtest-upgrade

Hey folks, I'm working on gathering coverage data across all of our test suites. The jvm-dtest-upgrade suite is currently unfriendly to Jacoco: it uses classes from multiple versions of Cassandra but with the same class names, so Jacoco's analysis fails due to "Can't add different class with sa

Re: [DISCUSS] Fixing coverage reports for jvm-dtest-upgrade

lassLoader was sad; in >> general this seems like it'd be a big help to debugging startup / env >> issues, assuming it doesn't break anything. :) >> >> On Fri, Mar 15, 2024, at 4:41 PM, Abe Ratnofsky wrote: >>> Hey folks, >>> >>> I'

Re: [DISCUSS] Modeling JIRA fix version for subprojects

CEP-8 proposes using separate Jira projects per Cassandra sub-project: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation > We suggest distinct Jira projects, one per driver, all to be created. I don't see any discussion changing that from the [DISCUSS] or vo

Cassandra Code Coverage Reports

Hey folks, Recently I put together per-suite and consolidated code coverage reports in advance of our upcoming releases. I’ve uploaded them to a static site on GitHub Pages so you can view them without downloading anything: https://aber.io/cassandra-coverage-reports Disclaimers: This is just f

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

Congrats everyone! > On Apr 17, 2024, at 1:10 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 java driver sub-project. > > Thank

Re: [DISCUSS] ccm as a subproject

Strong supporter for bringing ccm into the project as well. ccm is necessary test infrastructure for multiple subprojects, and Cassandra committers should be able to make the changes to ccm that are necessary for their patches. There's also the security angle: we should work to consolidate our d

Re: [DISCUSS] Adding experimental vtables and rules around them

I agree that ClientWarning is the best way to indicate the risk of using an experimental feature directly to the user. Presenting information in the client application's logs directly means that the person who wrote the query is most likely to see the warning, rather than an operator who sees cl

Re: [DISCUSS] Stream Pipelines on hot paths

+1 to forbidding Stream usage entirely; the convenience of using them outside of hot paths is less than the burden of figuring out whether or not a particular path is hot. Even for reviewers it can be difficult to tell whether a particular path is hot; hard-to-diagnose bugs like CASSANDRA-18110

Re: [DISCUSS] CEP-42: Constraints Framework

Hey Bernardo, Thanks for the proposal and putting together your summary of the discussion. A few thoughts: I'm not completely convinced of the value of CONSTRAINTS for a database like Cassandra, which doesn't support any referential integrity checks, doesn't do read-before-write for all querie

Re: [DISCUSS] CEP-42: Constraints Framework

I've thought about this some more. It would be useful for Cassandra to support user-defined "guardrails" (or constraints, whatever you want to call them), that could be applied per keyspace or table. Whether a user or an operator is considered the owner of a table depends on the organization dep

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congrats Dinesh! Thank you Josh! > On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan > wrote: > > Welcome to the Chair role Dinesh! Congrats! > > On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie > wrote: >> Another PMC Chair baton pass incoming! On behalf of the Apache

Re: [DISCUSS] spark-cassandra-connector donation to Analytics subproject

Likewise - another vote in favor of bringing in this subproject. Any thoughts on bringing in dsbulk as well? dsbulk has a lower barrier to entry than Spark Cassandra Connector, addresses a real need for users, and appears to be at a similar place in its project lifecycle. Abe > On Jun 24, 2024

Re: [DISCUSS] CEP-42: Constraints Framework

If we're going to introduce a feature that looks like SQL constraints, we should make sure it's "reasonably" compliant. In particular, we should avoid situations where a user creates a constraint, writes some data, then reads data that violates that constraint, unless they've expressed that viol

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

+1

Re: [VOTE] CEP-42: Constraints Framework

+1 (nb) > On Jul 2, 2024, at 12:15 PM, Yifan Cai wrote: > > +1 on CEP-42. > > - Yifan > > On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad > wrote: >> +1 >> >> On Tue, Jul 2, 2024 at 5:06 AM > > wrote: >>> +1 >>> >>> On Jul 1, 2024,

Re: Welcome Joey Lynch as Cassandra PMC member

Congratulations!

Re: Welcome Doug Rohrer as Cassandra Committer

Congratulations Doug!