Supportive and would welcome the contribution as well. Jon, thanks for your willingness to offer this work to the Foundation.
Also supportive of considering easy-cass-stress the successor to cassandra-stress. I’m fine with a directional goal of deprecating and removing cassandra-stress, but would like to make sure we have a successor to compaction-stress before doing so. I very rarely use cassandra-stress, but compaction-stress is helpful for generating a large corpus of SSTables and allowing compaction to churn through them. This is great for benching changes to the read path, compaction strategies, and for evaluation of hardware/VM/IO performance. https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/CompactionStress.java Apologies if this exists in easy-cass-stress today - I may have missed it. Our own documentation even lacks a mention of compaction-stress. :) – Scott > On Oct 13, 2024, at 8:01 PM, Štefan Miklošovič <smikloso...@apache.org> wrote: > > * easy-cass-stress, sorry. Everything else holds. > > On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič <smikloso...@apache.org > <mailto:smikloso...@apache.org>> wrote: >> What does "replacing" actually mean? If this tool is added to a separate >> repository, you mean like it would be put there under the "easy-cass-lab" >> name and all source code of cassandra-stress in the Cassandra repository >> would be removed? Are we going to deprecate what we have first or it is >> going to be a big bang? >> >> Should not be easy-cass-lab renamed to "cassandra-stress"? I do not think >> that "easy-cass-lab" should be the name of a repo we are going to use. For >> a custom tool living outside of Cassandra until now, sure, but the official >> stress tool should not be called "easy-cass-lab". People would be like ... >> what? IMHO we should rename it to cassandra-stress. >> >> On Sun, Oct 13, 2024 at 8:33 PM Brad <bscho...@gmail.com >> <mailto:bscho...@gmail.com>> wrote: >>> I'm +1 on replacing the existing cassandra-stress. My team did some work >>> last Summer to remove Thrift related CLI args, but arg parsing alone is a >>> 5K line mess. It's certainly not being well-maintained and could use a >>> replacement. >>> >>> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie <jmcken...@apache.org >>> <mailto:jmcken...@apache.org>> wrote: >>>> Unsolicited .02: >>>>> - If this will eventually replace the in-tree cassandra-stress, does it >>>>> warrant a CEP ? (i'm ok with skipping, though that step might have >>>>> encouraged the questions above) >>>> I'm +1 to this replacing, -0 on requiring a CEP. >>>> >>>> Given the current tool is unmaintained and doesn't (to my knowledge) have >>>> a workflow-based usage paradigm that could be easily extended, seems like >>>> a clear win. >>>> >>>> >>>> On Sat, Oct 12, 2024, at 7:31 AM, Mick Semb Wever wrote: >>>>> reply below. >>>>> >>>>> I’m terms of next steps: Mick what do we need to do next? Figure out the >>>>> answers to your questions re: getting contributor sign off? >>>>> >>>>> >>>>> >>>>> The process of donation is as follows… (feel free to correct me, or add >>>>> anything) >>>>> >>>>> >>>>> 1. General pre-agreement from the PMC that we'll take this project in, >>>>> and how it will fit in. >>>>> >>>>> Some questions I (personally) have are, >>>>> - Is the PMC ok with accepting a kotlin repository into the main part of >>>>> the project ? (I assume so, kotlin == java, just asking the question. >>>>> this was asked before, maybe i missed any response) >>>>> - Who are the initial three PMC members that are volunteering to be >>>>> active ? (Jon, Jordan, and ?) >>>>> - How will the activity in this repository maintain visibility to the >>>>> rest of the project ? (see recent discussions wrt sidecar's activity >>>>> silo-ing) >>>>> - Is the repo intending to adopt general project practices ? (e.g. >>>>> release formalities, "patch by ; reviewed by for " commit messages, etc >>>>> etc etc. if not, what is planned…) >>>>> - If this will eventually replace the in-tree cassandra-stress, does it >>>>> warrant a CEP ? (i'm ok with skipping, though that step might have >>>>> encouraged the questions above) >>>>> >>>>> >>>>> 2. IP Donation. Start filling out the IP Donation¹ form². >>>>> >>>>> Part of this process is to get approval to donate and an ICLA from each >>>>> individual past contributor. In addition any company involved in past >>>>> works must consent through either an SGA or their CCLA. In this case, >>>>> all work before SHA 2d4542c27d3f1c0e24899c01247b9a8ee3c9a238 was >>>>> copyrighted³ to The Last Pickle which is now owned by DataStax. Given >>>>> that copyright was over an entire body of work I would say that the SGA⁴ >>>>> is appropriate. (I'm happy to handle this.) We only need approval and >>>>> ICLA's from contributors after⁵ that SHA, as the previous copyright to >>>>> The Last Pickle applied to all past contributions. >>>>> >>>>> >>>>> 3. When the form, and all its steps are complete, raise a vote on >>>>> dev@cassandra.a.o and general@incubator.a.o >>>>> >>>>> >>>>> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) to >>>>> move the repository to github.com/apache/cassandra-stress >>>>> <http://github.com/apache/cassandra-stress> (or whatever, but keep the >>>>> cassandra- prefix IMO). >>>>> >>>>> -- >>>>> ¹) https://incubator.apache.org/ip-clearance/ip-clearance-template.html >>>>> ²) >>>>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/cassandra-java-driver.xml >>>>> >>>>> ³) >>>>> https://github.com/thelastpickle/tlp-stress/blob/master/LICENSE.txt#L1 >>>>> ⁴) https://www.apache.org/licenses/contributor-agreements.html >>>>> ⁵) >>>>> https://github.com/rustyrazorblade/easy-cass-stress/compare/2d4542c27d3f1c0e24899c01247b9a8ee3c9a238...main >>>>> >>>>> >>>>> >>>>> >>>>> >>>>
