You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Vinay Chella (Jira)" <ji...@apache.org> on 2020/12/03 22:07: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=17243538#comment-17243538 ] 

Vinay Chella commented on CASSANDRA-15580:
------------------------------------------

[Alexander Dejanovski|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=adejanovski], the detailed repair test plan that you outlined looks like a great start to me. I want to share a few techniques and methodologies that we use internally to validate the repair functionality though many are not in an open source-able state.

One of the things that are not covered in dtest repair test coverage is the repair validation with dense nodes, which is often the pain point. We have built an infrastructure and automation that helps us build large scale clusters with dense nodes, running NdBench traffic while repairing the cluster with continuous node restarts and terminations. This tooling and infra certainly helped us discover a few critical repair issues and tweaks in the past (e.g., CASSANDRA-14096). This infra also helps generate the data in one region and reading, validating in another region while node terminations and hints dropping are in place. Looking at the approach you are taking, I am glad that we are marching in a similar direction for 4.0 repair validation, which is a positive signal. 

Regarding mixed version upgrade tests, the similar approach that I outlined above certainly works to an extent. However, in-jvm upgrade dtests might be more feasible at this time.
{quote}Which testing framework to use?
 I personally like using Gherkin syntax based frameworks such as Cucumber, but we'd need to get a feel for the community's appetite to introduce such a framework.
 Otherwise we'd probably fallback to JUnit but my take on this is that while it's really good for unit tests, it's no fit for integration tests.
 Any input/opinion on testing framework is appreciated.{color:#172b4d} {color}
{quote}
I see a place where it makes integration tests more readable and easy to contribute to with something like Gherkin syntax based frameworks, so I don't see any downside and am optimistic on this unless someone has substantial concerns.

I am happy to help with the review of these efforts. Please loop me in these tickets as you make progress.

Thank you for taking this up.

 

> 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
>            Assignee: Alexander Dejanovski
>            Priority: Normal
>             Fix For: 4.0-rc
>
>
> Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.
> *Shepherd: Alexander Dejanovski*
> 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