[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308551#comment-17308551
]
Alex Petrov commented on CASSANDRA-16262:
-----------------------------------------
[~cscotta] sure. In fact, I've started working to make this possible. The first
pull request is to Harry and it is here:
https://github.com/apache/cassandra-harry/pull/7
There are several more things that I'd like to finish before we can start
testing in earnest. On Harry side we only need to implement partition deletions
(which is mostly ready), and implement statics (slightly more involved change,
since it requires us to separate partition-level updates from row-level ones
for efficiency). Other than that Harry tooling is adequate in my opinion.
After this, we only need to hook up Harry into Cassandra tests, and add a
simple QT-like DSL for generating schema and data, and then making checks and
validations, and start running these tests for several hundred hours at very
least, preferably more. FWIW, we do not strictly have to hook it up to
Cassandra codebase, but I think it'll make it more accessible, since most
people are already familiar with how to run Cassandra tests.
> 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
> Fix For: 4.0-rc
>
>
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
