> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- source arte
Again I am coming at this from the operator/end user perspective.
Creating a metrics dashboard, and then I am looking at those metrics to
understand what my queries are doing. We have coordinator query level
metrics, and then we have lower level table metrics on the replicas. I
want to be able t
Right. SAI queries are distributed range queries that produce local
single-partition reads. They should absolutely not be recorded in the local
range read latency metric. I'm fine ultimately with a new metric or the
existing local single-partition read metric.
On Fri, Dec 1, 2023 at 1:02 PM J. D.
At the coordinator level SAI queries fall under Range metrics. I would either put them under the same at the lower level or in a new SAI metric.It would be confusing to have the top level coordinator query metrics in Range and the lower level in Read. On Dec 1, 2023, at 12:50 PM, Caleb Rackliffe w
So the plan would be to have local "Read" and "Range" remain unchanged in
TableMetrics, but have a third "SAIRead" (?) just for SAI post-filtering
read SinglePartitionReadCommands? I won't complain too much if that's what
we settle on, but it just depends on how much this is a metric for
ReadComman
So excited for this program! It's been a long time coming but wow, what a
great way to recognize individuals advocating for Cassandra in their own
communities.
Let's get out there and start nominating!
Patrick
On Fri, Dec 1, 2023 at 9:51 AM Melissa Logan wrote:
> The Cassandra community is exc
I prefer option 2. It is much easier to understand and roll up two metrics than to do subtractive dashboards.SAI reads are already “range reads” for the client level metrics, not regular reads. So grouping them into the regular read metrics at the lower level seems confusing to me in that sense as
The Cassandra community is excited to introduce the Cassandra Catalyst
program, a new initiative that aims to recognize individuals who invest in
the growth of the community by enthusiastically sharing their expertise,
encouraging participation, and creating a welcoming environment.
This is the fi
Option 1 would be my preference. Seems both useful to have a single metric
for read load against the table and a way to break out SAI reads
specifically.
On Fri, Dec 1, 2023 at 11:00 AM Mike Adamson wrote:
> Hi,
>
> We are looking at adding SAI post-filtering reads to the local table
> metrics a
Hi,
We are looking at adding SAI post-filtering reads to the local table
metrics and would like some feedback on the best approach.
We don't think that SAI reads are that special so they can be included in
the table latencies, but how do we handle the global counts and the SAI
counts? Do we need
s2e13 - Jonathan Ellis
(You may have to download it to play)
https://drive.google.com/file/d/1XNfVyIrTM1AIdqzrSDeww7Xe05f8pIdD/view?usp=sharing
It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, December 4th.
If anyone should have any questions or comments, pl
+1 (nb)
> On Dec 1, 2023, at 7:32 AM, Mick Semb Wever wrote:
>
>
>
> Proposing the test build of Cassandra 5.0-beta1 for release.
>
> sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465
> Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative
> Maven Artifacts:
> https://repository.ap
Proposing the test build of Cassandra 5.0-beta1 for release.
sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465
Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1321/org/apache/cassandra/cassandra-a
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
With vetoes this vote does not pass.
19011 has been committed, I
Thanks for the exhaustive response, Alex :)
Let me bring my point of view:
1. Since long tests are just unit tests that take a long time to run, it
makes sense to separate them for efficient parallelization in CI. Since we
are adding new tests, modifying the existing ones, etc., that should be
so
15 matches
Mail list logo