+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> 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 > >
