4.0 QA Signup

The overarching goal of the 4.0 release is that Cassandra 4.0 should be at a state where major users would run it in production when it is cut. To gain this confidence there are various ongoing testing efforts involving correctness, performance, and ease of use. In this page we try to coordinate and identify blockers for subsystems before we can release 4.0

Tracking

We will track progress in Jira by tagging high level components with the 4.0-QA Jira label. We as a community can see our progress via a simple Jira query:

Jira Query for Tracking Progress

For each component we strive to have shepherds and contributors involved. Shepherds should be committers or knowledgeable component owners and are responsible for driving their blocking tickets to completion and ensuring quality in their claimed area, while contributors have signed up to help verify that subsystem by running tests or contributing fixes. Shepherds also ideally help set testing standards and ensure that we meet a high standard of quality in their claimed area.

If you are interested in contributing to testing 4.0, please add your name as a contributor and get involved in the the tracking ticket, and dev list/IRC discussions involving that component.

Targeted Components

We've tried to collect some of the major components or subsystems that we want to ensure work properly towards having a great 4.0 release. If you think something is missing please add it. Better yet volunteer to contribute to testing it!

Internode Messaging

In 4.0 we're getting a new Netty based inter-node communication system (CASSANDRA-8457). As internode messaging is vital to the correctness and performance of the database we should make sure that all forms (TLS, compressed, low latency, high latency, etc ...) of internode messaging function correctly.

Shepherd: Jason Brown

Tracking Ticket: CASSANDRA-14746

Contributors: Vinay Chella, Jordan West, Dinesh Joshi, Joey Lynch, Sumanth Pasupuleti

Storage Engine

We are still finding numerous bugs and issues with the 3.0 storage engine refactor ( CASSANDRA-8099). For 4.0 we want to ensure that we thoroughly cover the storage engine with techniques such as property-based testing and fuzzing (example).

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Repair

We aim for 4.0 to have the first fully functioning incremental repair solution (CASSANDRA-9143)! Furthermore we aim to verify that all types of repair: (full range, sub range, incremental) function as expected as well as ensuring community tools such as Reaper work.

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Transient Replication

One of the more exciting experimental features shipping with 4.0 is transient replication (CASSANDRA-14697). Let's make sure that users can use this feature without fear when running 4.0.

Shepherd: ?

Tracking Ticket: CASSANDRA-14697

Contributors: ?

Metrics

In past releases we've unknowingly broken metrics integrations and introduced performance regressions in metrics collection and reporting. We strive in 4.0 to not do that. Metrics should work well!

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Tooling

Cassandra ships with a lot of tools, and 4.0 includes some new ones like full query and audit logging (CASSANDRA-13983, CASSANDRA-12151). Let's do an e2e audit to make sure that all our tools work as expected so users won't find these bugs upon first use. This could also cover testing external tools such as Reaper, Priam, etc if people want to volunteer testing those.

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Cluster Setup and Maintenance

We want 4.0 to be easy for users to setup out of the box and just work. This means having low friction when users download the Cassandra package and start running it. For example, users should be able to easily configure and start new 4.0 clusters and have tokens distributed evenly. Another example is packaging, it should be easy to install Cassandra on all supported platforms (e.g. packaging) and have Cassandra use standard platform integrations.

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Cluster Upgrade

We've historically had numerous bugs concerning upgrading clusters from one version to the other. Let's establish the supported upgrade path and ensure that users can safely perform the upgrades in production.

Shepherd: ?

Tracking Ticket: ?

Contributors: ?

Documentation

Many sections of our documentation are incomplete or wrong. Let's deliver a functional but also well documented 4.0 release.

Shepherd: ?

Tracking Ticket: ?

Contributors: ?