[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472002#comment-17472002 ]
Alex Petrov commented on CASSANDRA-16262: ----------------------------------------- [patch|https://github.com/apache/cassandra/pull/1382] This introduces several ways to test Cassandra with Harry. 1. Creating unit tests using the history builder {code} test(new SchemaGenerators.Builder("harry") .partitionKeySpec(1, 5) .clusteringKeySpec(1, 5) .regularColumnSpec(1, 10) .generator(), historyBuilder -> { historyBuilder.nextPartition() .simultaneously() .randomOrder() .partitionDeletion() .rangeDeletion() .finish(); }); {code} 2. Generating SSTables {code} SSTableLoadingVisitor sstableVisitor = new SSTableLoadingVisitor(run, 1000); LtsVisitor visitor = new GeneratingVisitor(run, sstableVisitor); Set<Long> pds = new HashSet<>(); run.tracker.onLtsStarted((lts) -> { pds.add(run.pdSelector.pd(lts, run.schemaSpec)); }); for (int i = 0; i < 1000; i++) visitor.visit(); sstableVisitor.forceFlush(0); {code} 3. "normal" Harry capabilities (i.e. generate data using visitors and validate them using the model). > 4.0 Quality: Coordination & Replication Fuzz Testing > ---------------------------------------------------- > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz > Reporter: Caleb Rackliffe > Assignee: Alex Petrov > Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.20.1#820001) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org