You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Josh McKenzie (Jira)" <ji...@apache.org> on 2020/10/01 13:12:00 UTC
[jira] [Commented] (CASSANDRA-15580) 4.0 quality testing: Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205502#comment-17205502 ]
Josh McKenzie commented on CASSANDRA-15580:
-------------------------------------------
{quote}(full range, sub range, incremental)
4.0 only + mixed-version (3.11.x + 4.0)
{quote}
My bid is that we test (and automate and integrate in ci) the combination of the 6 states above where not yet covered. I'm pretty sure reaper validation is covered by CASSANDRA-15584. I'd bid for building these tests in [fallout|[https://github.com/datastax/fallout]] specifically to get nemeses and adverse cluster states in play (packet loss, node down, etc) during the repair process as well to ensure the repair process works as expected. Fallout's currently ASLv2 though not contributed to the project and ASF governance (much like ccm) though that's more because of a lack of conversation / appetite to take it on than anything. Happy to donate it to the project if other devs were interested.
If we don't go the fallout route, we'd need to chew on another longer running test automation framework running real clusters w/gen + validation. Either way, I think either time-based (1 hour gen + validation) or size-based (xGB workload) would be appropriate to make sure we have confidence in the extent to which we exercise the work.
What do you think [~bdeggleston]?
> 4.0 quality testing: Repair
> ---------------------------
>
> Key: CASSANDRA-15580
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15580
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
> Reporter: Josh McKenzie
> Priority: Normal
> Fix For: 4.0-beta
>
>
> Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.
> *Shepherd: Blake Eggleston*
> 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. CASSANDRA-3200 adds an experimental option to reduce the amount of data streamed during repair, we should write more tests and see how it works with big nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org