av9ash/GitBugs huggingface dataset:
Bug: Can't send schema pull request: node /A.B.C.D is down
Status: Triage Needed
Priority: Normal
Created: 16/Mar/20 17:08

On a new cluster with Cassandra 3.11.5, each time a node joins the cluster the schema pull request happens before at least 1 node is confirmed up.  On the first node it's fine but node #2 and following are all complaining with below WARN.

 
{noformat}
INFO [MigrationStage:1] 2020-03-16 16:49:32,355 ColumnFamilyStore.java:426 - Initializing system_auth.roles
WARN [MigrationStage:1] 2020-03-16 16:49:32,368 MigrationTask.java:67 - Can't send schema pull request: node /A.B.C.D is down.
WARN [MigrationStage:1] 2020-03-16 16:49:32,369 MigrationTask.java:67 - Can't send schema pull request: node /A.B.C.D is down.
INFO [main] 2020-03-16 16:49:32,371 Gossiper.java:1780 - Waiting for gossip to settle...
INFO [GossipStage:1] 2020-03-16 16:49:32,493 Gossiper.java:1089 - InetAddress /A.B.C.D is now UP
INFO [HANDSHAKE-/10.205.45.19] 2020-03-16 16:49:32,545 OutboundTcpConnection.java:561 - Handshaking version with /A.B.C.D

{noformat}
 

It's not urgent to fix but the WARN create noise for no reason.  Before trying to pull the schema, shouldn't the process wait for gossip to have at least 1 node "up"?
Bug: A possible read repair bug
Status: Triage Needed
Priority: Normal
Created: 24/Feb/20 03:46

cassandra version：2.1.15

i have one dc and 3nodes 

1. 
{code}
create KEYSPACE test WITH replication = \{'class': 'NetworkTopologyStrategy', 'DC1':'3' } and durable_writes = 'true';
{code}

2. 

{code}
create table test(a int , b int , c int , primary key(a)) with dclocal_read_repair_chance = 1.0;
{code}

3. 
{code}
insert one row into table test，instert into test(a, b, c) values (1, 1, 1);
{code}
 
and remove sstable on two nodes and result below：
{code}
    node1：have correct row 1 1 1

    node2：doesn't have rf

    node3：doesn't have rf
{code}
4. and i use local_one select one by one like this:
{code}
    node1 un，node2 dn，node3 dn：return 1 1 1

    node1 dn，node2 un，node3 dn：return null

    node1 dn，node2 dn，node3 dn：return null 
{code}
    this prove node1 have correct rf

5. and i let all node un，user local_quarum to {{select , select * from test where a = 1;}}

    but the read repair does't work every time(i test many times)，that's the problem(same in 3.0.15)

 

i hope if i set dclocal_read_repair_chance = 1.0，every time i read by local_quarum， if any rf digest does't match，read repair will work，and repair all nodes

 

i.m not sure does's the problem happends in this code()

wish for your reply，thanks

{code}
public void response(MessageIn<TMessage> message)
    {
        resolver.preprocess(message);        int n = waitingFor(message)
              ? recievedUpdater.incrementAndGet(this)
              : received;        if (n >= blockfor && resolver.isDataPresent())
        {
            ////this mean if return responses >= rf/2 +1 and a data response return，it start compare，does't all response
            condition.signalAll();            // kick off a background digest comparison if this is a result that (may have) arrived after            // the original resolve that get() kicks off as soon as the condition is signaled            if (blockfor < endpoints.size() && n == endpoints.size())
            {
                TraceState traceState = Tracing.instance.get();                if (traceState != null)
                    traceState.trace("Initiating read-repair");
                StageManager.getStage(Stage.READ_REPAIR).execute(new AsyncRepairRunner(traceState));
            }
        }
    }
{code}
Bug: Nodetool toppartitions error
Status: Awaiting Feedback
Priority: Normal
Created: 09/Mar/20 09:54

c* version :3.0.15

here's my test table：
CREATE TABLE app300.test (
 a bigint PRIMARY KEY,
 b text,
 c text
)

INSERT INTO app300.test(a ,b, c ) VALUES (500000, 'test1', 'test1');

when i use topartition ：nodetool  toppartitions app300 test 500000，get error

error: Expected 8 or 0 byte long (1048576)
-- StackTrace --
org.apache.cassandra.serializers.MarshalException: Expected 8 or 0 byte long (1048576)
	at org.apache.cassandra.serializers.LongSerializer.validate(LongSerializer.java:42)
	at org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:128)
	at org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1579)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)




but when i flush this table， topartition can work
Bug: Need microsecond precision for dropped columns so we can avoid timestamp issues
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 09/Mar/20 14:00
Resolved: 30/Mar/20 15:11

In CASSANDRA-15557 the fix for the flaky test is reimplementing the logic from CASSANDRA-12997  which was removed as part of CASSANDRA-13426

However, since dropped columns are stored at a millisecond precision instead of a microsecond precision and ClientState.getTimestamp adds microseconds on each call we will lose the precision on save and some writes that should be dropped could reappear.

Note views affected as well
 [https://github.com/apache/cassandra/blob/cb83fbff479bb90e9abeaade9e0f8843634c974d/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L712-L716]
Bug: running cassandra source code in eclipse
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 16/Mar/20 18:10
Resolved: 16/Mar/20 18:17

Hi . I installed cassandra on ubuntu and worked with it, i want to build and compile and run source code of cassandra in eclipse ,now.

my problem is this error : r: Could not find or load main class org.apache.cassandra.thrift.CassandraDaemon error

and i cant run source code of cassandra in eclipse , I dont know my previous steps for running source code of cassandra in eclipse is correct or not. 

please , please , please , please, please help me and tell me steps of building , compiling , running cassandra source code in eclipse . 

 

my email : [nnasim41@gmail.com|mailto:nnasim41@gmail.com] 

 

please help me :((((((
Bug: Cassandra repair failing 
Status: Awaiting Feedback
Priority: Normal
Created: 11/Mar/20 15:57

[2020-03-10 18:09:51,533] Repair session 7be9f3c0-631e-11ea-8e47-ef25c77f7899 for range [(6301399909211397355,6302095577836606571], (6301291625775958686,6301399909211397355], (6302095577836606571,6313970392023331777], (6297705134651154643,6301291625775958686]] finished (progress: 44%)
Exception occurred during clean-up. java.lang.reflect.UndeclaredThrowableException
Cassandra has shutdown.
error: [2020-03-10 18:09:56,868] JMX connection closed. You should check server log for repair status of keyspace cortex(Subsequent keyspaces are not going to be repaired).
-- StackTrace --
java.io.IOException: [2020-03-10 18:09:56,868] JMX connection closed. You should check server log for repair status of keyspace cortex(Subsequent keyspaces are not going to be repaired).
 at org.apache.cassandra.tools.RepairRunner.handleConnectionFailed(RepairRunner.java:98)
 at org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:86)
 at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:286)
 at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:363)
 at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:348)
 at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:259)
 at javax.management.remote.rmi.RMIConnector.sendNotification(RMIConnector.java:452)
 at javax.management.remote.rmi.RMIConnector.access$1200(RMIConnector.java:132)
 at javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin.gotIOException(RMIConnector.java:1542)
 at javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs(RMIConnector.java:1363)
 at com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.fetchOneNotif(ClientNotifForwarder.java:667)
 at com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.fetchNotifs(ClientNotifForwarder.java:619)
 at com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.doRun(ClientNotifForwarder.java:483)
 at com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.run(ClientNotifForwarder.java:464)
 at com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:120)
Bug: sstable not in the corresponding level in the leveled manifest
Status: Open
Priority: Normal
Created: 10/Mar/20 01:40

I get the following warning logs when running smoke tests

bq. Live sstable /cassandra/d1/data/ks/table-cce7c54b5abf3f369bb7659a74e9e963/mf-71-big-Data.db from level 0 is not on corresponding level in the leveled manifest. This is not a problem per se, but may indicate an orphaned sstable due to a failed compaction not cleaned up properly.

There are no other warning logs and no error logs; so compaction doesn’t have anything saying there was a failure.

Schema

{code}
CREATE TABLE ks.table (
  pk1 ascii,
  pk2 bigint,
  ck1 ascii,
  ck2 ascii,
  ck3 ascii,
  v1 int,
  v2 ascii, 
  PRIMARY KEY ((pk1,pk2), ck1, ck2, ck3)
) WITH comment = 'test table'
  AND gc_grace_seconds = 1
  AND memtable_flush_period_in_ms = 100
  AND compression = {'class': 'LZ4Compressor'}
  AND compaction = {'class': 'LeveledCompactionStrategy', 'only_purge_repaired_tombstones': true}
  AND CLUSTERING ORDER BY (ck1 DESC,ck2 ASC,ck3 DESC);
{code}

test
* run simulated queries for 30 minutes
* run incremental repair in a loop (once one completes run the next)
Bug: Remove obsolete table/MV options from schema tables
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 26/Feb/20 18:49
Resolved: 04/Mar/20 18:19

CASSANDRA-13910 removed the {{read_repair_chance}} and {{dclocal_read_repair_chance}} options for tables and materialized views.

CASSANDRA-12868 made {{default_time_to_live}} illegal for materialized views.

However the corresponding columns still exist in {{system_schema.tables}} and {{system_schema.views}}. Maybe it would make sense to remove them in Cassandra 4. Historically, obsolete options have been removed in similar cases, for example {{compaction_strategy_class}}, {{compaction_strategy_options}} and {{compression_parameters}} were present in 2.2 but removed in 3.0 (arguably there was also a major refactoring of schema tables during that transition).

This is not a huge deal, but it would make things a bit easier for the Java driver (our metadata exposes a "client-side describe" feature, and currently we assume that any column in the schema table must be added to the CREATE TABLE statement).
Bug: LOCAL_QUORUM is waiting on remote datacenter
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 04/Mar/20 11:59
Resolved: 04/Mar/20 14:53

We have a 2 datacenters ( One in EU and one in US ) cluster with 4 nodes each deployed in AWS. 
The nodes are separated in 3 racks ( Availability zones ) each.
In the cluster we have a keyspace test with replication: NetworkTopologyStrategy, eu-west:3, us-east:3
In the keyspace we have a table called mytable that has only one row 'id' text

Now, we were doing some tests on the performance of the database.
In CQLSH with a consistency level of LOCAL_QUORUM we were doing some inserts with TRACING ON and we noticed that the requests were not working as we expected them.

From the tracing data we found out that the coordinator node was hitting as expected 2 other local nodes and was also sending a request to one of the remote datacenter nodes. Now the problem here was that the coordinator was waiting not only for the local nodes ( who finished in no time ) but for the remote nodes too.

Now since our 2 datacenters are geographically far away from each other, our requests were taking a very long time to complete.

Notes:
- This does not happen with DSE but our understanding was we don't need to pay crazy money for LOCAL_QUORUM to work as is expected
Bug: Upgrade io.netty_netty-all dependency to fix security vulnerabilities
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Feb/20 03:31
Resolved: 24/Feb/20 14:28

Upgrade io.netty_netty-all dependency to fix the following CVEs:
 * [CVE-2019-20444|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20444]
 * [CVE-2019-20445|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20445]
 * [CVE-2019-16869|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16869]
Bug: Describe keyspace does not work for keyspaces with transient replication
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 18/Feb/20 09:14
Resolved: 18/Feb/20 18:12

I can not describe a keyspace which is using transient replication.
{code:java}
admin@cqlsh> CREATE KEYSPACE bar WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '3/1'};

admin@cqlsh> DESCRIBE KEYSPACE bar;

'NoneType' object has no attribute 'export_for_schema'
{code}
I am sorry in case this is a duplicate but I have not found similar issue yet.

 

This was tried on 4.0-alpha3
Bug: There is a spelling mistake in system_auth.resource_role_permissons_index
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 18/Feb/20 07:08
Resolved: 18/Feb/20 08:39

The system_auth keyspace has an error in a table named as resource_role_permissons_index. Should be resource_role_permissions_index(missing i in permissions)

cqlsh 5.0.1 | Cassandra 3.11.5
Bug: Node distribution in us-east-1 is uneven
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 10/Feb/20 19:02
Resolved: 10/Feb/20 20:08

nodetool status on 10.0.88.138 node gave pretty inconsistent distribution in us-east-1:-

[user@ip-10-0-88-138 cassandra]$ nodetool status
Datacenter: us-east
===================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address   Load   Tokens   Owns  Host ID               Rack
UN 10.0.93.177 17.22 TB 256     ?   bfe1d84b-eac9-4132-afca-35fde09377c4 1d
UN 10.0.91.41  1.07 TB  256     ?   bff1158e-985d-4ace-a152-1cd5747d58ca 1a
UN 10.0.91.90  2.35 TB  256     ?   5230d506-3675-47e9-a8a6-8a59ec94c303 1a
UN 10.0.88.138 1.59 TB  256     ?   ff21fbac-ae71-48d8-8d78-e638b98dd3ed 1a
UN 10.0.90.186 877.51 GB 256     ?   ef58c52b-73fe-406e-adfd-09585b5da5ed 1a
UN 10.0.93.123 5.6 TB  256     ?   d29dbd92-174d-47bf-aeb4-5376aa05e352 1d
UN 10.0.89.60  1.08 TB  256     ?   ae8e25b5-e336-4bbc-853c-54574cd0814f 1a
UN 10.0.91.237 1.25 TB  256     ?   085234df-6b46-4c9b-a512-9db034271458 1a
UN 10.0.92.62  5.5 TB  256     ?   3b02ad6f-ed92-4fd6-8725-b2105f26ead3 1d
Datacenter: us-west-2
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address   Load   Tokens   Owns  Host ID               Rack
UN 10.3.192.211 1.55 TB  256     ?   d6e47a22-e479-4df5-b1d7-a9c25a93d0e6 2a
UN 10.3.194.246 1.56 TB  256     ?   343a8828-1d94-4845-85bd-eaa3fde6115c 2a
UN 10.3.193.139 1.58 TB  256     ?   469d4a8d-a88d-42d2-a332-2dac1b03b7e7 2a
UN 10.3.197.153 1.55 TB  256     ?   6b2db4b7-d3df-4a82-93ec-a8913c741bcd 2c
UN 10.3.197.47 1.41 TB  256     ?   c4636cb0-4419-4900-b5c2-2a62767b1513 2c
UN 10.3.198.15 1.52 TB  256     ?   4fec0a33-16bf-420b-adda-2807290de2f1 2c
UN 10.3.192.127 1.58 TB  256     ?   837e8256-7d29-4db4-b746-0a7aed8409a4 2a
UN 10.3.196.190 1.63 TB  256     ?   99580b60-b329-4912-89c0-677be342c3af 2c


df -h on the node:-
Filesystem   Size Used Avail Use% Mounted on
devtmpfs     30G  68K  30G  1% /dev
tmpfs      30G   0  30G  0% /dev/shm
/dev/xvda1   126G 6.4G 120G  6% /
/dev/nvme0n1  1.8T 786G 868G 48% /var/cassandra/data-0
Bug: Use the ASF process for packaging and uploading deb files
Status: Triage Needed
Priority: Normal
Created: 04/Feb/20 06:27

Use the ASF process for packaging and uploading deb files.

https://cwiki.apache.org/confluence/display/INFRA/Packaging+a+deb+and+uploading+to+Bintray

The current process is found in https://github.com/apache/cassandra-builds/tree/master/cassandra-release
Bug: Cassandra nodes did not respond
Status: Resolved
Priority: Normal
Resolution: Not A Bug
Created: 07/Feb/20 21:18
Resolved: 07/Feb/20 21:25

The following cassandra nodes failed to respond giving Exception:-

10.0.88.138 Cassandra node
10.0.91.41
10.0.89.60
10.0.90.186
10.0.91.90

2020-02-06 19:35:58:337 thread=https-jsse-nio-8443-exec-125, level=ERROR, logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], , message="Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.datastax.driver.core.exceptions.OperationTimedOutException: [/10.0.88.138:9042] Timed out waiting for server response] with root cause"
com.datastax.driver.core.exceptions.OperationTimedOutException: [/10.0.88.138:9042] 

2020-02-06 19:35:35:907 thread=https-jsse-nio-8443-exec-97, level=ERROR, logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], , message="Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded)] with root cause"

nodetool status on 10.0.88.138  node gave pretty inconsistent distribution in us-east-1:-
Datacenter: us-east
===================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address   Load   Tokens   Owns  Host ID               Rack
UN 10.0.93.177 17.22 TB 256     ?   bfe1d84b-eac9-4132-afca-35fde09377c4 1d
UN 10.0.91.41  1.07 TB  256     ?   bff1158e-985d-4ace-a152-1cd5747d58ca 1a
UN 10.0.91.90  2.35 TB  256     ?   5230d506-3675-47e9-a8a6-8a59ec94c303 1a
UN 10.0.88.138 1.59 TB  256     ?   ff21fbac-ae71-48d8-8d78-e638b98dd3ed 1a
UN 10.0.90.186 877.51 GB 256     ?   ef58c52b-73fe-406e-adfd-09585b5da5ed 1a
UN 10.0.93.123 5.6 TB  256     ?   d29dbd92-174d-47bf-aeb4-5376aa05e352 1d
UN 10.0.89.60  1.08 TB  256     ?   ae8e25b5-e336-4bbc-853c-54574cd0814f 1a
UN 10.0.91.237 1.25 TB  256     ?   085234df-6b46-4c9b-a512-9db034271458 1a
UN 10.0.92.62  5.5 TB  256     ?   3b02ad6f-ed92-4fd6-8725-b2105f26ead3 1d
Datacenter: us-west-2
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address   Load   Tokens   Owns  Host ID               Rack
UN 10.3.192.211 1.55 TB  256     ?   d6e47a22-e479-4df5-b1d7-a9c25a93d0e6 2a
UN 10.3.194.246 1.56 TB  256     ?   343a8828-1d94-4845-85bd-eaa3fde6115c 2a
UN 10.3.193.139 1.58 TB  256     ?   469d4a8d-a88d-42d2-a332-2dac1b03b7e7 2a
UN 10.3.197.153 1.55 TB  256     ?   6b2db4b7-d3df-4a82-93ec-a8913c741bcd 2c
UN 10.3.197.47 1.41 TB  256     ?   c4636cb0-4419-4900-b5c2-2a62767b1513 2c
UN 10.3.198.15 1.52 TB  256     ?   4fec0a33-16bf-420b-adda-2807290de2f1 2c
UN 10.3.192.127 1.58 TB  256     ?   837e8256-7d29-4db4-b746-0a7aed8409a4 2a
UN 10.3.196.190 1.63 TB  256     ?   99580b60-b329-4912-89c0-677be342c3af 2c
Bug: Add a warning when RF > N
Status: Triage Needed
Priority: Normal
Created: 05/Feb/20 15:03

When testing Cassandra with network partitions, we find that keyspace creation can succeed without any warning even if there are not enough nodes to support the replication factor. Here are the steps to reproduce:
 # Start a cluster w/ two nodes.
 # Create a keyspace with replication factor of three.
 # Notice that the creation succeeds without any warning.
Bug: commit logs fill up disk space
Status: Triage Needed
Priority: Normal
Created: 05/Feb/20 13:31

We have a three-nodes Cassandra cluster with version 3.11.3 in our production environment and the configuration 'commitlog_total_space_in_mb' is set to 8192.

 

After tens of days running, commit logs at the third node grow upto about 300G and run out of disk space finally. The amount of commitlog files is about 10K. We have to remove all commitlog files at this node and restart Cassandra to repair it.

 

I wonder if there any reason or bug could result in the size of commitlog exceed commitlog_total_space_in_mb ? In our other production environment with the same configurations, Cassandra cluster works well.
Bug: Operation timeout when creating a keyspace/table.
Status: Triage Needed
Priority: Normal
Created: 05/Feb/20 04:29

When testing Cassandra with network partitions, we have observed the following failure from time to time:
 # Start a three-node cluster, say node1, node2, and node3.
 # Partition node3 from node1 and node2.
 # Use cqlsh to contact node1 to create a keyspace/table. The cqlsh and node1 runs on the same host.
 # Notice that cqlsh fails with the following error:

{code:java}
<stdin>:1:OperationTimedOut: errors={'127.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1{code}
Bug: Update defaults for the validity timeframe of roles, permissions, and credentials for 4.0
Status: Triage Needed
Priority: Normal
Created: 24/Jan/20 04:01

It's been found that the defaults for \{{roles_validity_in_ms}}, \{{permissions_validity_in_ms}}, and \{{credentials_validity_in_ms}} have been too low at 2000 ms or 2 seconds each.  As [~alexott] put it in the dev list discussion about defaults:
{quote}I have seen multiple times when authentication was failing under the heavy load because queries to system tables were timing out - with these defaults people may still have the possibility to get updates to roles/credentials faster when specifying _update_interval_ variants of these configurations.
{quote}
The suggestion is to set it to 60000 (1 minute) or 120000 (2 minutes).
Bug: split circle ci commands into reusable scripts which can be used outside of circle ci
Status: Open
Priority: Normal
Created: 24/Jan/20 01:03

CircleCI is one of the main tools we use for build and test, but there is also ASF Jenkins and many people run builds in their own companies as well. It would be nice to refactor the existing CircleCI yaml to delegate to a set of scripts which could be reused by other build systems.

I feel that we could do the following directory layout

{code}
ci - top level directory containing all scripts
 - <test type : unit, distributed> - directory containing the different build steps
     - <test name : eg. unit, jvm-dtest, long, etc.> - a single build with the required steps to run it
         - split.sh - script which takes in a output file to write to and dumps out all test cases (not partitioned)
         - run_partition.sh - script which takes a partitioned list of tests and executes the build (does not move around artifacts)
{code}

This would allow CircleCI and Jenkins to run the same way, but also acts as documentation for how to run some of the tests (jvm-dtest and python dtest upgrade tests take more time to figure out how to run).

CircleCI would also be simpler as it would mostly be the circle ci specific logic (partition tests, move code/test results around, etc.) calling these scripts.
Bug: Update default snitch from SimpleSnitch to GossipingPropertyFileSnitch
Status: Triage Needed
Priority: Normal
Created: 24/Jan/20 04:09

Traditionally the project has had {{SimpleSnitch}} as the default primarily because it makes it easy for a user to download the software and start Cassandra without changing any defaults and it will just work.  However, {{SimpleSnitch}} is not datacenter aware.  {{GossipingPropertyFileSnitch}} could also be used as the default and would make the default snitch be datacenter aware.  Out of the box it will work with the default configuration.

This ticket would be to update the default from {{SimpleSnitch}} to {{GossipingPropertyFileSnitch}} to make the onboarding experience better for those who don't know to change this default if they intend to expand to multiple datacenters without too much hassle.