I did mean the md file, which explains all internal intricacies. Also there is a blog post [1]
My plan was to: 1. Introduce easily copiable samples 2. add more Java doc 3. Talk to other contributors and collect information about missing pieces / how to make it more accessible I might ask for help when we have some better understanding of what we want to achieve. Thank you —Alex [1] https://cassandra.apache.org/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html On Tue, Jan 2, 2024, at 10:54 PM, Lorina Poland wrote: > Is there any user-facing documentation (for developers) that should be added? > I note that you say there is "extensive documentation"; I presume that you > are referring to the README.md in the repo? > > If there is a desire to add documentation to the website, as opposed to the > MD files in the repo, please reach out to me. > > Thanks, > Lorina > > On 2023/12/21 21:22:54 Alex Petrov 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 > > >
