+1 ________________________________ From: Patrick McFadin <pmcfa...@gmail.com> Sent: Friday, December 22, 2023 9:12 AM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: [EXTERNAL] Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")
It was great having some more extended discussions about Harry in person last week. Anything we can do to make it easier for anyone to test Cassandra thoroughly is an easy +1 from me! Thanks for all your efforts so far, Alex. Patrick On Fri, Dec 22, 2023 at 8:03 AM Jacek Lewandowski <lewandowski.ja...@gmail.com<mailto:lewandowski.ja...@gmail.com>> wrote: Obviously +1 Thank you Alex pt., 22 gru 2023, 16:45 użytkownik Sumanth Pasupuleti <sumanth.pasupuleti...@gmail.com<mailto:sumanth.pasupuleti...@gmail.com>> napisał: +1, thank you for your efforts in bringing Harry in-tree. Anything that improves the testing ecosystem for Cassandra, particularly around complex scenarios / edge cases goes a long way in improving reliability, and with having a powerful tool like Harry in-tree, it is a lot more accessible to the developers than it has been. Also, thank you for keeping in mind the onboarding experience of developers. - Sumanth On Fri, Dec 22, 2023 at 1:11 AM Alex Petrov <al...@coffeenco.de<mailto:al...@coffeenco.de>> wrote: Some follow-up tickets to establish the project direction: https://issues.apache.org/jira/browse/CASSANDRA-19229 Two other things that we will work on in Tree are: https://issues.apache.org/jira/browse/CASSANDRA-18275 (model and in-JVM test for partition-restricted 2i queries) https://issues.apache.org/jira/browse/CASSANDRA-18667 (multi-threaded SAI read and write fuzz test) If you would like to get your recently added feature tested with Harry model, please let me know! On Fri, Dec 22, 2023, at 12:41 AM, Joseph Lynch wrote: +1 Sounds like a great change that will help us unify around a common testing paradigm, and even pave the path to in-tree load testing plus integrated correctness checking which would be extremely valuable! -Joey On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe <calebrackli...@gmail.com<mailto:calebrackli...@gmail.com>> wrote: +1 Agree w/ all the justifications mentioned above. As a reviewer on CASSANDRA-19210<https://issues.apache.org/jira/browse/CASSANDRA-19210>, my goals were to a.) look at the directory, naming, and package structure of the ported code, b.) make sure IDE integration was working, and c.) make sure any modifications to existing code (rather than direct code movements from cassandra-harry) were straightforward. On Thu, Dec 21, 2023 at 3:23 PM Alex Petrov <al...@coffeenco.de<mailto:al...@coffeenco.de>> wrote: Hey folks, I am mostly done with a patch that brings Harry in-tree [1]. I will trigger one more CI run overnight, and my intention was to merge it some time soon, but I wanted to give a fair warning here, since this is a relatively large patch. Good news for everyone that it: a) touches no production code whatsoever. Only test (in-jvm dtest namely) code that was using Harry already. b) the only tests that are changed are ones that used a duplicate version of placement simulator we had both for testing TCM, and in Harry c) in addition, I have converted 3 existing TCM tests to a new API to have some base for examples/usage. Since we were effectively relying on this code for a while now, and the intention now is to converge to: a) fewer different generators, and have a shareable version of generators for everyone to use accross the base b) a testing tool that can be useful for both trivial cases, and complex scenarios myself and many other Cassandra contributors have expressed an opinion that bringing Harry in-tree will be highly benefitial. I strongly believe that bringing Harry in-tree will help to lower the barrier for fuzz test and simplify co-development of Cassandra and Harry. Previously, it has been rather difficult to debug edge cases because I had to either re-compile an in-jvm dtest jar and bring it to Harry, or re-compile a Harry jar and bring it to Cassandra, which is both tedious and time consuming. Moreover, I believe we have missed at very least one RT regression [2] because Harry was not in-tree, as its tests would've caught the issue even with the model that existed. For other recently found issues, I think having Harry in-tree would have substantially lowered a turnaround time, and allowed me to share repros with developers of corresponding features much quicker. I do expect a slight learning curve for Harry, but my intention is to build a web of simple tests (worked on some of them yesterday after conversation with David already), which can follow the in-jvm-dtest pattern of find-similar-test / copy / modify. There's already copious documentation, so I do not believe not having docs for Harry was ever an issue, since there have been plenty. You all are aware of my dedication to testing and quality of Apache Cassandra, and I hope you also see the benefits of having a model checker in-tree. Thank you and happy upcoming holidays, --Alex [1] https://issues.apache.org/jira/browse/CASSANDRA-19210 [2] https://issues.apache.org/jira/browse/CASSANDRA-18932
