I do have some familiarity w/ the codebase, and I could help support it in a minor capacity. (Reviews, small fixes, etc.) Probably not something I could spend hours on every week.On Apr 25, 2024, at 5:11 PM, Jon Haddad wrote:I should probably have noted - since TLP is no more, I renamed
I should probably have noted - since TLP is no more, I renamed tlp-stress
to easy-cass-stress around half a year ago when I took it over again.
Jon
On Thu, Apr 25, 2024 at 3:05 PM Jeff Jirsa wrote:
> Unless there’s 2-3 other people who expect to keep working on it, I don’t
> see how we justify
Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going
I am not familiar with ECS but if we’re going to go for it I would prefer
it to be a sub project really. Jon, what do you think?
On Thu, Apr 25, 2024 at 2:44 PM Brandon Williams wrote:
> I want to begin by saying I am generally +1 on this because I have
> become a fan of easy-cass-stress after
Yeah, I agree with your concerns. I very firmly prefer a separate
subproject. I've got zero interest in moving from a modern Gradle project
to an ant based one. It would be a lot of work for not much benefit.
If we wanted to replace cassandra-stress, I'd say bring in the release
artifact as
I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress? If
the latter, we are going to have to reconcile the build systems
somehow. I don't really
I have updated the CEP to use binary level file digest verification.
In the next iteration, I am going to address the below point.
> I would like to see more abstraction of how the files get moved / put in
place with the proposed solution being the default implementation. That
would allow others
I've been asked by quite a few people, both in person and in JIRA [1] about
contributing easy-cass-stress [2] to the project. I've been happy to
maintain the project myself over the years but given its widespread use I
think it makes sense to make it more widely available and under the
project's
All I say is we should be careful not to open the door for someone to be
able to set for a parameter in cassandra.yaml 512MiB and convert it to 0
GiB internally while changing those classes. Loss of precision and weird
settings. As long as that pandora box stays closed, all good
I do support
I can’t see a good reason not to support it. Seems like extra work to avoid
with no benefit.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Thu, Apr 25, 2024 at 7:16 AM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> Can you elaborate on intentionally not supporting
Can you elaborate on intentionally not supporting some conversions? Are we
safe to base these conversions on DataStorageUnit? We have set of units
from BYTES to GIBIBYTES and respective methods on them which convert from
that unit to whatever else. Is this OK to be used for the purposes of this
All I am saying is be careful with adding those conversions not to end up
used while setting our configuration. Thanks
On Thu, 25 Apr 2024 at 6:53, Štefan Miklošovič
wrote:
> Well, technically I do not need DataStorageSpec at all. All I need is
> DataStorageUnit for that matter. That can
Well, technically I do not need DataStorageSpec at all. All I need is
DataStorageUnit for that matter. That can convert from one unit to another
easily.
We can omit tebibytes, that's just fine. People would need to live with
gibibytes at most in cqlsh output. They would not get 5 TiB but 5120
Edit: I meant to say smaller to bigger unit, not size, sorry
On Thu, 25 Apr 2024 at 6:35, Ekaterina Dimitrova
wrote:
> Quick comment:
>
> DataRateSpec, DataStorageSpec, or DurationSpec
> - we intentionally do not support going smaller to bigger size in those
> classes which are specific for
Quick comment:
DataRateSpec, DataStorageSpec, or DurationSpec
- we intentionally do not support going smaller to bigger size in those
classes which are specific for cassandra.yaml - precision issues. Please
keep it that way. That is why the notion of min unit was added in
cassandra.yaml for
TiB is not yet in DataStorageSpec (perhaps we should add it).
A quick review tells me that all the units are unique across the 3 specs.
As long as we guarantee that in the future the method you propose should be
easily expandable to the other specs.
+1 to this idea.
On Thu, Apr 25, 2024 at
That is a very interesting point, Claude. My so-far implementation is
using FileUtils.stringifyFileSize which is just dividing a value by a
respective divisor based on how big a value is. While this works, it will
prevent you from specifying what unit you want that value to be converted
to as well
17 matches
Mail list logo
