> I think we should just accept easy-cass-stress as a subproject and go > from there. Replacing stress can be handled separately and still has > the large issue of reconciling the build systems that I raised in the > beginning of this thread, but can be figured out eventually.
I strongly agree with you here. The proposal is to just add the project > On Oct 14, 2024, at 11:08 AM, C. Scott Andreas <sc...@paradoxica.net> wrote: > > Separating the two is completely fine yep -- just mentioned since > deprecation/removal of stress also came up in the thread. > > Let's complete the donation. Just wanted to make sure we don't remove > compaction-stress without a substitute. > > – Scott > >> On Oct 14, 2024, at 10:46 AM, Brandon Williams <dri...@gmail.com> wrote: >> >> >> I think we should just accept easy-cass-stress as a subproject and go >> from there. Replacing stress can be handled separately and still has >> the large issue of reconciling the build systems that I raised in the >> beginning of this thread, but can be figured out eventually. >> >> Kind Regards, >> Brandon >> >> On Mon, Oct 14, 2024 at 12:41 PM Jon Haddad <j...@rustyrazorblade.com> wrote: >>> >>> Scott, I think introducing replacing compaction stress as a requirement >>> here adds unnecessary friction to the donation process. I'd prefer to avoid >>> coupling the two things. Unless you or someone else is volunteering to >>> rewrite it I think this would effectively halt the donation, which I doubt >>> is your intention. Can we do that as a separate thing? >>> >>> Regarding the name, I'm fine if we rename it. My tooling is easy-cass-*, >>> and renaming it would make it clear that it's no longer my project, that's >>> fine with me. >>> >>> Jon >>> >>> >>> On Sun, Oct 13, 2024 at 8:20 PM <sc...@paradoxica.net> wrote: >>>> >>>> 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> >>>> 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> 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> >>>>>> 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 <mailto:dev@cassandra.a.o> and general@incubator.a.o >>>>>>> <mailto:general@incubator.a.o> >>>>>>> >>>>>>> >>>>>>> 4. When the vote passes, request ASF Infra (create INFRA jira ticket) >>>>>>> to move the repository to github.com >>>>>>> <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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >
