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 wo
* easy-cass-stress, sorry. Everything else holds.
On Sun, Oct 13, 2024 at 9:00 PM Štefan Miklošovič
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 cassand
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
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 wrote:
> Unsolici
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 (
