Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Brandon Williams]

On Thu, Sep 19, 2024 at 2:16 PM Štefan Miklošovič
 wrote:
> Unfortunately there is nothing like that for Ant, protoc would need to be a 
> local dependency on the computer which compiles the project to be able to do 
> that so that is kind of a dead end. Or is there any workaround here?

In the old thrift days I believe we generated the code and checked it
in so you didn't need to compile locally.

Kind Regards,
Brandon

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Brandon Williams]

My concern is that we have to keep making sure it's not phoning home(1,2).

(1) https://issues.apache.org/jira/browse/CASSANDRA-18538
(2) https://issues.apache.org/jira/browse/CASSANDRA-19656

Kind Regards,
Brandon

On Mon, Sep 16, 2024 at 7:53 PM Josh McKenzie  wrote:
>
> I think it's FQLTool only right now; I bumped into it recently doing the 
> JDK21 compat work.
>
> I'm not concerned about current usage / dependency, but if our usage expands 
> this could start to become a problem and that's going to be a hard thing to 
> track and mange.
>
> So reading through those issues Stefan, I think it boils down to:
>
> The latest ea is code identical to the stable release
> Subsequent bugfixes get applied to the customer-only stable branch and one 
> release forward
> Projects running ea releases would need to cherry-pick those bugfixes back or 
> run on the next branch's ea, which could introduce the project to API changes 
> or other risks
>
> Assuming that's the case... blech. Our exposure is low, but that seems like a 
> real pain.
>
> On Mon, Sep 16, 2024, at 5:16 PM, Benedict wrote:
>
>
> Don’t we essentially just use it as a file format for storing a couple of 
> kinds of append-only data?
>
> I was never entirely clear on the value it brought to the project.
>
>
> On 16 Sep 2024, at 22:11, Jordan West  wrote:
>
> 
> Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It 
> sounds like a replacement is not really practical so I'll ignore that option 
> for now, until a viable alternative is proposed. I am -1 on us writing our 
> own without strong, strong justification -- primarily because I think the 
> likelihood is we introduce more bugs before getting to something stable.
>
> Regarding the remaining options, mostly some thoughts:
>
> - it would be nice to have some specific evidence of other projects using the 
> EA versions and what their developers have said about it.
> - it sounds like if we go with the EA route, the onus to test for correctness 
> / compatibility increases. They do test but anything marked "early access" I 
> think deserves more scrutiny from the C* community before release. That could 
> come in the form of more tests (or showing that we already have good coverage 
> of where its used).
> - i assume each time we upgrade we would pick the most recently released EA 
> version
>
> Jordan
>
>
> On Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič  
> wrote:
>
> We are using a library called Chronicle Queue (1) and its dependencies and we 
> ship them in the distribution tarball.
>
> The version we use in 5.0 / trunk as I write this is 2.23.36. If you look 
> closely here (2), there is one more release like this, 2.23.37 and after that 
> all these releases have "ea" in their name.
>
> "ea" stands for "early access". The project has changed the versioning / 
> development model in such a way that "ea" releases act, more or less, as 
> glorified snapshots which are indeed released to Maven Central but the 
> "regular" releases are not there. The reason behind this is that "regular" 
> releases are published only for customers who pay to the company behind this 
> project and they offer commercial support for that.
>
> "regular" releases are meant to get all the bug fixes after "ea" is published 
> and they are official stable releases. On the other hand "ea" releases are 
> the ones where the development happens and every now and then, once the 
> developers think that it is time to cut new 2.x, they just publish that 
> privately.
>
> I was investigating how this all works here (3) and while they said that, I 
> quote (4):
>
> "In my experience this is consumed by a large number of open source projects 
> reliably (for our other artifacts too). This development/ea branch still goes 
> through an extensive test suite prior to release. Releases from this branch 
> will contain the latest features and bug fixes."
>
> I am not completely sure if we are OK with this. For the record, Mick is not 
> overly comfortable with that and Brandon would prefer to just replace it / 
> get rid of this dependency (comments / reasons / discussion from (5) to the 
> end)
>
> The question is if we are OK with how things are and if we are then what are 
> the rules when upgrading the version of this project in Cassandra in the 
> context of "ea" versions they publish.
>
> If we are not OK with this, then the question is what we are going to replace 
> it with.
>
> If we are going to replace it, I very briefly took a look and there is 
> practically nothing out there which would hit all the buttons for us. 
> Chronicle is just perfect for this job and I am not a fan of rewriting this 
> at all.
>
> I would like to have this resolved because there is CEP-12 I plan to deliver 
> and I hit this and I do not want to base that work on something we might 
> eventually abandon. There are some ideas for CEP-12 how to bypass this 
> without using Chronicle but I would like to firstly hear your opi

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

+1 for declaring things like this in the vote/release emails.

Kind Regards,
Brandon

On Sun, Sep 15, 2024 at 10:17 AM Michael Shuler  wrote:
>
> I've stated this same opinion prior, fix was in NEWS.txt and users had a
> bad day with a behavior change. Perhaps this kind of inclusion needs
> more exposure. This is exactly the sort of change may *also* be best
> stated clearly in the vote/release emails, ala:
>
> 
> ==
> This release contains a relatively major change you should be aware of,
> with xyz fix, new default, and with the behavior change, here are the
> new defaults, how to disable, etc...
> ==
> kthxbai.
>
> Just do everything possible to convey what operators need to know,
> wherever we can, if we include the fix. Link to NEWS.txt is insufficient
> in this sort of case.
>
> Warm regards,
> Michael
>
> On 9/12/24 13:16, Abe Ratnofsky wrote:
> > Expressing another vote in favor of rejection-by-default. If a user doesn't 
> > want to lose sleep for data loss while on-call, they can read NEWS.txt and 
> > disable rejection.
> >

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

On Thu, Sep 12, 2024 at 8:34 PM Josh McKenzie  wrote:
> I'm not advocating for us having a rigid principled stance where we reject 
> all nuance and don't discuss things. I'm advocating for us coalescing on a 
> shared default stance of correctness unless otherwise excepted. We know we're 
> a diverse group, we're all different people with different histories / values 
> / opinions / cultures, and I think that's what makes this community as 
> effective as it is.
>
> But I don't think it's healthy for us to repeatedly re-litigate whether data 
> loss is acceptable based on how long it's been around, or how frequently some 
> of us on the project have observed some given phenomenon. My gut tells me 
> we'd all be in a better place if we all started from 0 on a discussion like 
> this as "Ok, data loss is unacceptable. Unless otherwise warranted, we should 
> do all we can to fix this on all supported branches as our default response".

I think this absolutely makes sense in situations where things are
clear cut and just need to be corrected, like an off-by-one error.  We
discover the problem, we fix it.

However, the current situation is not that.  You say age is not
relevant, and though that may be true for the age of the bug (which is
before my time!), I do think it's relevant that we've known about this
(documented by the ticket) for at least 7 years, but only now have
decided to address it.  Furthermore, this isn't a straight correction,
from the very beginning a possible tradeoff with availability in some
circumstances was mentioned.  We are talking about changing behavior
on top of a 200k delta in ~4k lines of code across a significant
amount of files, and doing so in the 13th minor release of a 4 year
old major, for a problem we have known about long enough to have put
this in all current major releases.  I don't think painting the
picture with the "data loss" brush alone tells us everything we need
to know to make that kind of commitment to what is now our old stable
branch.

That said, I want to thank Scott and others who provided helpful
context here.  I still think it is in the realm of possibility that
changing behavior can cause a problem for an existing user, and they
will be right to be angry if that happens, but that is an easier pill
to swallow if we are possibly preventing data loss that is easier to
encounter than previously thought.  I support doing this in all the
current branches.

Kind Regards,
Brandon

Re: Welcome Chris Bannister, James Hartig, Jackson Flemming and João Reis, as cassandra-gocql-driver committers

[Brandon Williams]

Congratulations!

Kind Regards,
Brandon

On Thu, Sep 12, 2024 at 6:40 AM Mick Semb Wever  wrote:
>
> The PMC's members are pleased to announce that Chris Bannister, James Hartig, 
> Jackson Flemming and João Reis have accepted invitations to become committers 
> on the Drivers subproject.
>
> Thanks a lot for everything you have done with the gocql driver all these 
> years.  We are very excited to see the driver now inside the Apache Cassandra 
> project.
>
> Congratulations and welcome!!
>
> The Apache Cassandra PMC

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

On Thu, Sep 12, 2024 at 1:13 PM Caleb Rackliffe
 wrote:
>
> I think I can count at least 4 people on this thread who literally have lost 
> sleep over this.

Probably good examples of not being the majority though, heh.

If we are counting on users to read NEWS.txt, can we not count on them
to enable rejection if this is important to them?

Kind Regards,
Brandon

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

On Thu, Sep 12, 2024 at 11:52 AM Josh McKenzie  wrote:
>
> More or less surprising than learning that they've been at risk of or 
> actively losing data for years?

Ignorance is bliss though and I think the majority of users haven't
lost sleep over this since it's been present since the beginning of
time.  Changing behavior in old stable branches can interrupt that,
especially if a regression is introduced, which is always a
possibility.  Logging will provide awareness and I think that's going
far enough on our side, and users who are concerned can go further on
theirs.

Kind Regards,
Brandon

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

On Thu, Sep 12, 2024 at 11:41 AM Caleb Rackliffe
 wrote:
>
> Are you opposed to the patch in its entirety, or just rejecting unsafe 
> operations by default?

I had the latter in mind.  Changing any default in a patch release is
a potential surprise for operators and one of this nature especially
so.

Kind Regards,
Brandon

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Brandon Williams]

On Thu, Sep 12, 2024 at 11:07 AM Caleb Rackliffe
 wrote:
>
> The one consequence of that we might discuss here is that if gossip is behind 
> in notifying a node with a pending range, local rejection as it receives 
> writes for that range may cause a small issue of availability.

I don't think this should be done in a patch release.

Kind Regards,
Brandon

Re: [VOTE] Release test-api 0.0.17

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Sep 10, 2024 at 9:36 AM Doug Rohrer  wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.17 for release
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
>
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/85b538ca8259dedc2aded8a633cf3174f551f664
> Tagged with 0.0.17
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1343/org/apache/cassandra/dtest-api/0.0.17/
>
> Key signature: 9A648E3DEDA36EE374C4277B602ED2C52277
>
> Changes since last release:
> * CASSANDRA-19783 - In-jvm dtest to detect InstanceClassLoaderLeaks
> * CASSANDRA-19239 - jvm-dtests crash on java 17
>
> The vote will be open for 24 hours. 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.

Re: [VOTE] Release Apache Cassandra 5.0.0

[Brandon Williams]

I agree neither seems to be a blocker as long as 1) is still clean, +1.

Kind Regards,
Brandon

On Wed, Sep 4, 2024 at 7:47 AM Štefan Miklošovič  wrote:
>
> I am +1 but I found two "issues" along the way.
>
> for 1) I do not think this is a blocker, what is important is that at the 
> time of the release we verified that there are no new vulnerabilities found 
> (and these which owasp found are identified as suppressed / not valid)
>
> for 2) that brings inconvenience for users who need to set the flags on their 
> own. "bash .build/docker/build-debian.sh" does not work either for me at 
> least.
>
> 1) https://issues.apache.org/jira/browse/CASSANDRA-19895
> 2) https://issues.apache.org/jira/browse/CASSANDRA-19896
>
> On Mon, Sep 2, 2024 at 12:12 PM Mick Semb Wever  wrote:
>>
>>
>> Proposing the test build of Cassandra 5.0.0 for release.
>>
>> sha1: 186272edca920c757b91bf95c2392bafa1a38d72
>> Git: https://github.com/apache/cassandra/tree/5.0.0-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1342/org/apache/cassandra/cassandra-all/5.0.0/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and 
>> repositories, are available here: 
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0.0/
>>
>> 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]: CHANGES.txt: 
>> https://github.com/apache/cassandra/blob/5.0.0-tentative/CHANGES.txt
>> [2]: NEWS.txt: 
>> https://github.com/apache/cassandra/blob/5.0.0-tentative/NEWS.txt

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

[Brandon Williams]

Congrats to you both!

Kind Regards,
Brandon

On Fri, Aug 30, 2024 at 3:21 PM Jon Haddad  wrote:
>
> The PMC's members are pleased to announce that Jordan West and Stefan 
> Miklosovic have accepted invitations to become PMC members.
>
> Thanks a lot, Jordan and Stefan, for everything you have done for the project 
> all these years.
>
> Congratulations and welcome!!
>
> The Apache Cassandra PMC

Re: [VOTE] Release Apache Cassandra 5.0-rc2

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Aug 22, 2024 at 6:58 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 5.0-rc2 for release.
>
> sha1: 06691fce25a215361332aa1767e188bb6694687a
> Git: https://github.com/apache/cassandra/tree/5.0-rc2-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1341/org/apache/cassandra/cassandra-all/5.0-rc2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc2/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc2-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc2-tentative/NEWS.txt

[RELEASE] Apache Cassandra 4.1.6 released

[Brandon Williams]

[RELEASE] Apache Cassandra 4.1.6 released

The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.1.6.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 4.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now
https://debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/41x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-4.1.6/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.1.6/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [VOTE] Release Apache Cassandra 4.1.6 - take 2

[Brandon Williams]

With five +1 (four binding) and no -1, the vote passes.  I'll work on
getting the release published.

On Wed, Aug 14, 2024 at 11:54 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.6 for release.
>
> sha1: 790de1079811278a2b431c2ced7c7ea02d290a25
> Git: https://github.com/apache/cassandra/tree/4.1.6-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1340/org/apache/cassandra/cassandra-all/4.1.6/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.6/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.6-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.6-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.6 - take 2

[Brandon Williams]

+1

On Wed, Aug 14, 2024 at 11:54 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.6 for release.
>
> sha1: 790de1079811278a2b431c2ced7c7ea02d290a25
> Git: https://github.com/apache/cassandra/tree/4.1.6-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1340/org/apache/cassandra/cassandra-all/4.1.6/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.6/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.6-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.6-tentative/NEWS.txt

[VOTE] Release Apache Cassandra 4.1.6 - take 2

[Brandon Williams]

Proposing the test build of Cassandra 4.1.6 for release.

sha1: 790de1079811278a2b431c2ced7c7ea02d290a25
Git: https://github.com/apache/cassandra/tree/4.1.6-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1340/org/apache/cassandra/cassandra-all/4.1.6/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.1.6/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/4.1.6-tentative/CHANGES.txt
[2]: NEWS.txt: https://github.com/apache/cassandra/blob/4.1.6-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.6

[Brandon Williams]

I have added this note and will reroll:
https://github.com/apache/cassandra/commit/790de1079811278a2b431c2ced7c7ea02d290a25

Kind Regards,
Brandon

On Mon, Aug 12, 2024 at 2:48 PM Jon Haddad  wrote:
>
> My preference is a NEWS.txt update and we reroll.
>
> On Fri, Aug 2, 2024 at 3:11 PM Brandon Williams  wrote:
>>
>> So where does this leave us with this release?  Get Alex's patch
>> committed and reroll, reroll with a NEWS entry, or... ?
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Aug 1, 2024 at 9:04 AM Tommy Stendahl via dev
>>  wrote:
>> >
>> > Hi,
>> >
>> > First, thanks everyone for considering this. I did not expect such a big 
>> > discussion form this, for me it was not such a big thing and a think 
>> > CASSANDRA-19534 is a very good improvement.
>> >
>> > If I have to recompile I would also update the code so I'm not sure I see 
>> > much benefit with compile time compatibility. What made me react and raise 
>> > the issue was the complete surprise that this would fail when I upgraded 
>> > my test cluster to 4.1.6. My expectation was that a change like this would 
>> > have been discussed or at least mentioned on the ML or Slack but I can't 
>> > remember seeing anything. A note in the NEWS-file would also have made 
>> > aware, I wouldn't have been super happy but I would have know what to 
>> > expect and what I had to do.
>> >
>> > ecaudit is one thing we do that use the QueryHandler interface but for our 
>> > internal we also use have a few implementations for query tracing/logging 
>> > and prioritize requests. I would say that the QueryHandler interface 
>> > together with the custom payload feature in the native protocol is a 
>> > powerful combination and I would not be surprised if this is used more 
>> > then you might expect.
>> >
>> > -Original Message-
>> > From: J. D. Jordan 
>> > Reply-To: dev@cassandra.apache.org
>> > To: dev@cassandra.apache.org
>> > Subject: Re: [VOTE] Release Apache Cassandra 4.1.6
>> > Date: Thu, 01 Aug 2024 08:26:42 -0500
>> >
>> > @Tommy do you think?  You brought the issue up, I am assuming because you 
>> > found the issue while trying to test ecaudit against the proposed release 
>> > and it broke the integration?
>> > As an active consumer of the interface what are your thoughts?
>> >
>> > On Aug 1, 2024, at 8:17 AM, Alex Petrov  wrote:
>> >
>> > 
>> > > If we have a path that resolves the issue and also maintains full 
>> > > compatibility for this (semi- / reluctantly-accessible) interface, that 
>> > > would seem ideal. Interested to learn more about the drawbacks to that 
>> > > approach.
>> >
>> > My thinking here was that people who might have a binary dependency on 
>> > this interface have to recompile their code, they may as well change 2 
>> > lines by adding a call to from the new method with 
>> > `requestTime.startedAtNanos()`. I am not in a strong opposition to merging 
>> > it though. If there is general agreement that this is the best way, let's 
>> > do this: I do not see any drawbacks in terms of performance or otherwise.
>> >
>> > If we decide to move forward with, it, the patch is up [1].
>> >
>> > [1] https://issues.apache.org/jira/browse/CASSANDRA-19811
>> >
>> > On Wed, Jul 31, 2024, at 11:24 PM, C. Scott Andreas wrote:
>> >
>> > Sorry to veer off from a vote in a vote thread.
>> >
>> > @Alex, can you say more about this statement:
>> >
>> > > "I think I would prefer to not introduce the change I have proposed (the 
>> > > one that would bring back non-binary compatibility)."
>> >
>> > If we have a path that resolves the issue and also maintains full 
>> > compatibility for this (semi- / reluctantly-accessible) interface, that 
>> > would seem ideal. Interested to learn more about the drawbacks to that 
>> > approach.
>> >
>> > Regarding the value of C-19534 I'm happy to attest to the fact that it 
>> > addresses severe metastable failure modes in clusters under heavy traffic 
>> > on the verge of tipping. Jon Haddad's independent testing validated this 
>> > as discussed on the ticket as well: 
>> > https://issues.apache.org/jira/browse/CASSANDRA-19534
>> >
>> > Last, @Tommy this is a great catch and I'm glad you rai

Re: [VOTE] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

[Brandon Williams]

+1 for reasons stated in the discussion.

Kind Regards,
Brandon

On Sun, Aug 4, 2024 at 1:18 AM Yifan Cai  wrote:
>
> Hi,
>
> I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0.
>
> There is a discussion thread on the topic. In summary, the backport would 
> benefit Cassandra Analytics by providing a unified solution, and the patch is 
> considered low-risk. While there are concerns about adding features to 4.0 
> and 4.1, there is generally support for 5.0.
>
> The vote will be open for 72 hours (longer if needed). Votes by PMC members 
> are considered binding. A vote passes if there are at least three binding +1s 
> and no -1's.
>
> Kind regards,
> Yifan Cai

Re: [VOTE] Release Apache Cassandra 4.1.6

[Brandon Williams]

ic facing API, which of the following 2 is more important:
>
> Keeping the API stable
> Having the defect resolved
>
> Obviously this will be case-by-case. What CASSANDRA-19534 addresses:
>
> When a node is under pressure, hundreds of thousands of requests can show up 
> in the native transport queue, and it looks like it can take way longer to 
> timeout than is configured.
> ...
> After stopping the load test altogether, it took nearly a minute before the 
> requests were no longer queued.
>
> I believe our priority here should be having this defect resolved.
>
> On Tue, Jul 30, 2024, at 1:43 PM, Jordan West wrote:
>
> I would make the case that loss of availability / significant performance 
> issue, regardless of the amount of time it has existed for, is worth fixing 
> on the branches that are widely deployed by the community. Especially when 
> weighed against a loosely defined public interface issue.
>
> The queuing issue has been a persistent problem (like you said 10 years) and 
> I regularly (approx once every 1-2 weeks) have to tell my customers “we 
> either have to wait for Cassandra to clear the queues or do a rolling restart 
> to fix it” both which come at a cost during an incident where a client 
> overloaded the DB and the impact is severe or business impacting. Especially 
> for customers doing LWTs or using non-standard RFs which are also more 
> prevalent in my experience than an external implementation of QueryHandler.
>
> While not data loss, I would argue this is a critical bug and if we did find 
> a data loss issue dormant for 10 years (which has happened in the past) we 
> would fix it as soon as it was found and a patch was made available on all 
> actively maintained versions.
>
> Jordan
>
> On Tue, Jul 30, 2024 at 10:30 Jeff Jirsa  wrote:
>
>
> It’s a 10 year old flaw in an 18 month old branch. Why does it need to go 
> into 4.1, it’s not a regression and it clearly breaks compatibility?
>
>
>
>
> On Jul 30, 2024, at 8:52 AM, Jon Haddad  wrote:
>
> This patch fixes a long standing issue that's the root cause of availability 
> failures.  Even though folks can specify a custom query handler with the -D 
> flag, the number of users impacted by this is going to be incredibly small.  
> On the other hand, the fix helps every single user of 4.1 that puts too much 
> pressure on the cluster, which happens fairly regularly.
>
> My POV is that it's a fairly weak argument that this is a public interface, 
> but I don't consider it worth debating whether it is or not, because even if 
> it is, this improves stability of the database for all users, so it's worth 
> going in.  Let's not be dogmatic about fixes that help 99% of users because 
> an incredibly small number that actually implement a custom query handler 
> will need to make a trivial update in order to use the latest 4.1.6 
> dependency.
>
> Jon
>
>
>
> On Tue, Jul 30, 2024 at 8:09 AM J. D. Jordan  
> wrote:
>
>
> Given we allow a pluggable query handler implementation to be specified for 
> the server with a -D during startup. So I would consider the query handler 
> one of our public interfaces.
>
> On Jul 30, 2024, at 9:35 AM, Alex Petrov  wrote:
>
> 
> Hi Tommy,
>
> Thank you for spotting this and bringing this to community's attention.
>
> I believe our primary interfaces are native and internode protocol, and CLI 
> tools. Most interfaces are used to to abstract implementations internally. 
> Few interfaces, such as DataType, Partitioner, and Triggers can be depended 
> upon by external tools using Cassandra as a library. There is no official way 
> to plug in a QueryHandler, so I did not consider it to be a part of our 
> public API.
>
> From [1]:
>
> > These considerations are especially important for public APIs, including 
> > CQL, virtual tables, JMX, yaml, system properties, etc. Any planned 
> > additions must be carefully considered in the context of any existing APIs. 
> > Where possible the approach of any existing API should be followed.
>
> Maybe we should have an exhaustive list of public APIs, and explicitly 
> mention that native and internode protocols are included, alongside with 
> nodetool command API and output, but also which classes/interfaces 
> specifically should be evolved with care.
>
> Thank you,
> --Alex
>
> [1] https://cassandra.apache.org/_/development/index.html
>
> On Tue, Jul 30, 2024, at 10:56 AM, Tommy Stendahl via dev wrote:
>
> Hi,
>
> There is a change in the QueryHandler interface introduced by 
> https://issues.apache.org/jira/browse/CASSANDRA-19534
>
&

Re: [DISCUSS] state of lz4-java

[Brandon Williams]

I just want to note that lz4 is used for network compression, either
between nodes or more importantly for clients, so interoperability is
key and we need to be careful about changing things here.

Kind Regards,
Brandon

On Fri, Aug 2, 2024 at 3:05 AM Štefan Miklošovič  wrote:
>
> I just want to raise awareness about lz4-java library we use for LZ4 
> compressor. We are using the version 1.8.0, there is already version 1.10.0 
> of the underlying lz4 project which lz4-java integrates.
>
> We can see from NEWS (1) that after 1.8.0 there are a lot of performance 
> improvements and in 1.10.0 they implemented multithreading compression (2) 
> which provides great compression times. This seems to be supported for "cli" 
> only, I am not completely sure yet if multithreaded compression would be 
> something which we might use for our case too though.
>
> Anyway, the thing is lz4-java seems to be a dead project. There is no 
> official release from 1.8.0, the submodule of lz4 was updated to 1.9.3 but it 
> was never released and the main contributor behind lz4-java is unresponsive. 
> (I even wrote him an email with no response yet). There are numerous requests 
> from users to release a new version, questions about the state of the project 
> but the response is none. It truly seems like the project was abandoned.
>
> That is quite unfortunate and I am not sure what we should do about that. I 
> think that people will eventually fork so the project might continue in some 
> fashion. Nevertheless, I think the state of that library is in a quite bad 
> position.
>
> We might look into alternatives but I do not think that switching it to 
> anything else will be easy because these custom libraries are often not 
> compatible between themselves as the way they implement the specification 
> might slightly vary.
>
> On lz4.org (1), there is Apache Commons listed as a lib which implements 
> block and frame specification and it is interoperable so maybe we might take 
> a look into how we would replace it if lz4-java is indeed abandoned?
>
> There is a note about lz4-java (or any lib in that category) like this:
>
> They use the block compression format, but add their own frame / header logic 
> (or none at all) Consequently, they are not interoperable with LZ4 command 
> line utility, nor (generally) between themselves.
>
> Do we even want to make any progress in this area or are we happy to have it 
> on 1.8.0 forever?
>
> (1) https://github.com/lz4/lz4/blob/dev/NEWS
> (2) https://github.com/lz4/lz4/blob/dev/NEWS#L2
> (3) https://lz4.org/

Re: [DISCUSS] introduction of SnapshotManagerMBean

[Brandon Williams]

On Thu, Aug 1, 2024 at 9:22 AM Jon Haddad  wrote:
>  I don't think we've deprecated or removed anything that mentions "column 
> family" or "cf" even though that hasn't been our user-facing terminology in 
> close to a decade.  Please correct me if I'm wrong on any of this.

Off the top of my head nodetool 'cfstats' was deprecated and replaced
by 'tablestats'

Kind Regards,
Brandon

[VOTE] Release Apache Cassandra 4.1.6

[Brandon Williams]

Proposing the test build of Cassandra 4.1.6 for release.

sha1: b662744af59f3a3dfbfeb7314e29fecb93abfd80
Git: https://github.com/apache/cassandra/tree/4.1.6-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1339/org/apache/cassandra/cassandra-all/4.1.6/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.1.6/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/4.1.6-tentative/CHANGES.txt
[2]: NEWS.txt: https://github.com/apache/cassandra/blob/4.1.6-tentative/NEWS.txt


Kind Regards,
Brandon

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

[Brandon Williams]

Given how low risk this is, I don't see an issue with backporting it
and I'm sure the usefulness outweighs what risk there is. +1 (5.0.1
though, not 5.0.0)

Kind Regards,
Brandon

On Fri, Jul 26, 2024 at 11:52 AM Yifan Cai  wrote:
>
> Hi everyone,
>
> CASSANDRA-19800 is currently in the state of ready to be committed. Before 
> that, I want to propose backporting it to 4.0, 4.1 and 5.0.
>
> The ability to notify CQLSSTableWriter user when new sstables are produced is 
> especially useful for Cassandra Analytics and other consumers. The API is 
> more reliable than monitoring the file directory.
>
> That being said, I am aware that the patch is an improvement and trunk only. 
> I want to ask for an exemption on backporting the patch for two reasons. It 
> is useful for Cassandra Analytics. The patch is low risk for Cassandra server 
> as it only touches CQLSSTableWriter, which is only used by toolings.
>
> - Yifan

Re: [RESULT}[VOTE] Release Apache Cassandra 5.0-rc1

[Brandon Williams]

A release is always coming ;)  I'll try to get the 4.1.6 ball rolling on Monday.

Kind Regards,
Brandon

On Wed, Jul 24, 2024 at 3:56 PM Elliott Sims via dev
 wrote:
>
> Looks like this is out and there's a 5.0-rc release.  Is a 4.1.6 release with 
> a fix for CASSANDRA-19668 coming?
>
> On Sat, Jun 29, 2024 at 2:39 AM Mick Semb Wever  wrote:
>>
>>
>> The votes fails with a veto in place having made CASSANDRA-19668 an 5.0-rc 
>> blocker.
>>
>> Once 19668 lands we will need an immediate release of 4.1.6 too.
>>
>>
>>
>> On Fri, 28 Jun 2024 at 06:49, Jon Haddad  wrote:
>>>
>>> Thanks for confirming this, Blake. I agree that we should not knowingly 
>>> ship new versions with severe bugs that cause the DB to crash, regression 
>>> or not.
>>>
>>> -1 from me as well
>>>
>>>
>>> On Fri, Jun 28, 2024 at 1:39 AM Blake Eggleston  
>>> wrote:

 Looking at the ticket, I’d say Jon’s concern is legitimate. The segfaults 
 Jon is seeing are probably caused by paxos V2 when combined with off heap 
 memtables for the reason Benedict suggests in the JIRA. This problem will 
 continue to exist in 5.0. Unfortunately, it looks like the patch posted is 
 not enough to address the issue and will need to be a bit more involved to 
 properly fix the problem.

 While this is not a regression, I think Jon’s point about trie memtables 
 increasing usage of off heap memtables is a good one, and anyway we 
 shouldn’t be doing major releases with known process crashing bugs.

 So I’m voting -1 on this release and will work with Jon and Benedict to 
 get this fixed.
>>
>>
>>
>>
>
>
> This email, including its contents and any attachment(s), may contain 
> confidential and/or proprietary information and is solely for the review and 
> use of the intended recipient(s). If you have received this email in error, 
> please notify the sender and permanently delete this email, its content, and 
> any attachment(s). Any disclosure, copying, or taking of any action in 
> reliance on an email received in error is strictly prohibited.

Re: Welcome Joey Lynch as Cassandra PMC member

[Brandon Williams]

Congrats!

Kind Regards,
Brandon

On Wed, Jul 24, 2024 at 9:12 AM Benjamin Lerer  wrote:
>
> The PMC's members are pleased to announce that Joey Lynch has accepted the 
> invitation to become a PMC member.
>
> Thanks a lot, Joey, for everything you have done for the project all these 
> years.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take3)

[Brandon Williams]

On Wed, Jul 17, 2024 at 2:36 PM Mick Semb Wever  wrote:
>
> Should we remove the noboolean rpm from the release, given we have no way to 
> verify or test it ?
> Effectively, dropping centos:7 support from 5.0.

I didn't look into whether or not there were other distros that might
need it.  I should hope not, and that we could remove noboolean, but I
don't know.

Kind Regards,
Brandon

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take3)

[Brandon Williams]

+1

Note that centos7 went EOL on June 30th; I didn't test the noboolean
packages as a result.

Kind Regards,
Brandon

On Wed, Jul 10, 2024 at 2:54 PM Mick Semb Wever  wrote:
>
> Proposing the third test build of Cassandra 5.0-rc1 for release.
>
> sha1: d85d6750f90eaf799709a05d2f1c31189fce04fd
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1338/org/apache/cassandra/cassandra-all/5.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc1/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt
>
>

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take2)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Jul 2, 2024 at 6:21 AM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 5.0-rc1 for release.
>
> sha1: 01eea8a0d74deaede236edb25335fa470502106e
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1337/org/apache/cassandra/cassandra-all/5.0-rc1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc1/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

[Brandon Williams]

On Mon, Jul 1, 2024 at 12:30 PM Jon Haddad  wrote:
>
> I also don't think keeping the output consistent needs to be a strict long 
> term requirement.  We *should* have either a JSON output option for every 
> command, or a virtual table for structured data.  I don't remember us ever 
> making a promise that human readable tools would keep consistent across major 
> versions.
>

We discussed this a bit here:
https://lists.apache.org/thread/72j5qfgbttjcmylhcmfq1ptboh641ns0

Kind Regards,
Brandon

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Brandon Williams]

I don't know that we expect to fix anything if we don't know it is
affected yet. ¯\_(ツ)_/¯

Kind Regards,
Brandon

On Thu, Jun 27, 2024 at 12:37 PM Aleksey Yeshchenko  wrote:
>
> Not voting on this, however, if we expect to fix something specific between 
> an RC and GA, then we shouldn’t be starting a vote on RC. In that case it 
> should be another beta.
>
> > On 27 Jun 2024, at 18:30, Brandon Williams  wrote:
> >
> > The last time paxos v2 blocked us in CASSANDRA-19617 which also
> > affected 4.1, I didn't get a sense of strong usage from the community,
> > so I agree that RC shouldn't be blocked but this can get fixed before
> > GA.  +1 from me.
> >
> > Kind Regards,
> > Brandon
> >
> > On Tue, Jun 25, 2024 at 11:11 PM Jon Haddad  wrote:
> >>
> >> 5.0 is a massive milestone.  A huge thank you to everyone that's invested 
> >> their time into the release.  I've done a lot of testing, benchmarking, 
> >> and tire kicking and it's truly mind blowing how much has gone into 5.0 
> >> and how great it is for the community.
> >>
> >> I am a bit concerned that CASSANDRA-19668, which I found in 4.1, will also 
> >> affect 5.0.  This is a pretty serious bug, where using Paxos v2 + off heap 
> >> memtables can cause a SIGSEV process crash.  I've seen this happen about a 
> >> dozen times with a client over the last 3 months.  Since the new trie 
> >> memtables rely on off heap, and both Trie memtables & Paxos V2 is so 
> >> compelling (esp for multi-dc users), I think there's a good chance that 
> >> we'll be making an already bad problem even worse, for folks that use LWT.
> >>
> >> Unfortunately, until next week I'm unable to put any time into this; I'm 
> >> on vacation with my family.  I wish I had been able to confirm and raise 
> >> this issue as a 5.0 blocker sooner, but I've deliberately tried to keep 
> >> work stuff out of my mind.   Since I'm not 100% sure if this affects 5.0, 
> >> I'm not blocking the RC, but I don't feel comfortable putting a +1 on a 
> >> release that I'm at least 80% certain contains a process-crashing bug.
> >>
> >> I have a simple 4.1 patch in CASSANDRA-19668, but I haven't landed a 
> >> commit in several years and I have zero recollection of the entire process 
> >> of getting it in, nor have I spent any time writing unit or dtests in the 
> >> C* repo.  I ran a test of 160MM LWTs over several hours with my 4.1 branch 
> >> and didn't hit any issues, but my client ran for weeks without hitting it 
> >> so it's hard to say if I've actually addressed the problem, as it's a rare 
> >> race condition.  Fwiw, I don't need to be the one to handle 
> >> CASSANDRA-19668, so if someone wants to address it before me, please feel 
> >> free.  It will likely take me a lot longer to deal with than someone more 
> >> involved with the process, and I'd want 2 sets of eyes on it anyways given 
> >> what I already mentioned previously about committing and testing.
> >>
> >> Jon
> >>
> >>
> >> On Tue, Jun 25, 2024 at 2:53 PM Mick Semb Wever  wrote:
> >>>
> >>>
> >>>
> >>> .
> >>>
> >>>> Proposing the test build of Cassandra 5.0-rc1 for release.
> >>>>
> >>>> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> >>>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> >>>> Maven Artifacts: 
> >>>> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
> >>>
> >>>
> >>>
> >>> The three green CI runs for this are
> >>> - 
> >>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-2
> >>> - 
> >>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-3
> >>> - 
> >>> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-4
> >>>
> >>>
>

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Brandon Williams]

The last time paxos v2 blocked us in CASSANDRA-19617 which also
affected 4.1, I didn't get a sense of strong usage from the community,
so I agree that RC shouldn't be blocked but this can get fixed before
GA.  +1 from me.

Kind Regards,
Brandon

On Tue, Jun 25, 2024 at 11:11 PM Jon Haddad  wrote:
>
> 5.0 is a massive milestone.  A huge thank you to everyone that's invested 
> their time into the release.  I've done a lot of testing, benchmarking, and 
> tire kicking and it's truly mind blowing how much has gone into 5.0 and how 
> great it is for the community.
>
> I am a bit concerned that CASSANDRA-19668, which I found in 4.1, will also 
> affect 5.0.  This is a pretty serious bug, where using Paxos v2 + off heap 
> memtables can cause a SIGSEV process crash.  I've seen this happen about a 
> dozen times with a client over the last 3 months.  Since the new trie 
> memtables rely on off heap, and both Trie memtables & Paxos V2 is so 
> compelling (esp for multi-dc users), I think there's a good chance that we'll 
> be making an already bad problem even worse, for folks that use LWT.
>
> Unfortunately, until next week I'm unable to put any time into this; I'm on 
> vacation with my family.  I wish I had been able to confirm and raise this 
> issue as a 5.0 blocker sooner, but I've deliberately tried to keep work stuff 
> out of my mind.   Since I'm not 100% sure if this affects 5.0, I'm not 
> blocking the RC, but I don't feel comfortable putting a +1 on a release that 
> I'm at least 80% certain contains a process-crashing bug.
>
> I have a simple 4.1 patch in CASSANDRA-19668, but I haven't landed a commit 
> in several years and I have zero recollection of the entire process of 
> getting it in, nor have I spent any time writing unit or dtests in the C* 
> repo.  I ran a test of 160MM LWTs over several hours with my 4.1 branch and 
> didn't hit any issues, but my client ran for weeks without hitting it so it's 
> hard to say if I've actually addressed the problem, as it's a rare race 
> condition.  Fwiw, I don't need to be the one to handle CASSANDRA-19668, so if 
> someone wants to address it before me, please feel free.  It will likely take 
> me a lot longer to deal with than someone more involved with the process, and 
> I'd want 2 sets of eyes on it anyways given what I already mentioned 
> previously about committing and testing.
>
> Jon
>
>
> On Tue, Jun 25, 2024 at 2:53 PM Mick Semb Wever  wrote:
>>
>>
>>
>> .
>>
>>> Proposing the test build of Cassandra 5.0-rc1 for release.
>>>
>>> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
>>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
>>> Maven Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>>
>>
>>
>> The three green CI runs for this are
>> - https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-2
>> - https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-3
>> - https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-4
>>
>>

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Jun 25, 2024 at 12:30 PM Mick Semb Wever  wrote:
>
>
>
> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html
>
> All consent from original authors of the donation, and tracking of collected 
> CLAs, is found in:
>  - https://github.com/gocql/gocql/issues/1751
>  - 
> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
> These do not require acknowledgement before the vote.
>
> The code is prepared for donation at https://github.com/gocql/gocql
>
> Once this vote passes we will request ASF Infra to move the gocql/gocql as-is 
> to apache/cassandra-gocql-driver  . The master branch and tags, with all 
> their history, will be kept.  Because consent and CLAs were not received from 
> all original authors the source files keep additional reference to their 
> earlier copyright authors and license.
>
> This will become part of the Drivers subproject, ref CEP-8: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>
> PMC members, please check carefully the IP Clearance requirements before 
> voting.
>
> The vote will be open for 72 hours (or longer). Votes by PMC members are 
> considered binding. A vote passes if there are at least three binding +1s and 
> no -1's.
>
> regards,
> Mick

Re: Suggestions for CASSANDRA-18078

[Brandon Williams]

Nothing else is blocking the release currently, so unless 18085 is
ready to commit right now, I don't think it's worth delaying the
release any further.

Kind Regards,
Brandon

On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad  wrote:
>
> I’m on vacation, so I’ll keep this brief.  While its not the end of the 
> world, I think shipping a feature that’s immediately deprecated reflects 
> poorly on the project and our ability to manage it.
>
> I don’t know how much work need to be done to merge that patch, so its hard 
> to say if we should wait for it or if we should ship 5.0 and make an 
> exception to add it in 5.0.1.  I’d prefer 5.0.1 but i won’t die on this hill.
>
> Jon
>
>
> On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever  wrote:
>>
>>
>>
>> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe  wrote:
>>>
>>> 100% Option 1. Once it's out in GA release we're stuck with it so any short 
>>> term disruption to adopters of pre-release versions is a trivial price to 
>>> pay.
>>
>>
>>
>> Sam, Jeremiah, Jeff, Jon,
>>
>>  we need some clarity on this.
>>
>> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes) first 
>> add CASSANDRA-18085.
>>
>> 18085 was slated for 5.x
>> Are we really going to both a) remove an API that was already released in a 
>> beta, and b) add in a new improvement into an rc ?
>>
>> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>>
>>

Re: [VOTE] CEP-24 Password validation / generation

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Jun 17, 2024 at 4:32 AM Štefan Miklošovič
 wrote:
>
> Hi everyone,
>
> I would like to start the voting for CEP-24 as all feedback in the discussion 
> threads seem to be addressed.
>
> Proposal: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=228494146
> JIRA under which it will be delivered: 
> https://issues.apache.org/jira/browse/CASSANDRA-17457
> Draft implementation: 
> https://github.com/instaclustr/cassandra/tree/CEP-24-simplified
>
> Discuss threads:
>
> https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1
> https://lists.apache.org/thread/1hs27lx2pw9lmp7rw499vn0m7vl2bgt1
>
> The reason there are two threads is that I replied to the first one after 
> that CEP was dormant for a very long time and it just created new thread for 
> that, most probably an issue with my e-mail client ...
>
> The vote will be open for 72 hours (longer if needed). A vote passes if there 
> are at least 3 binding +1s and no binding vetoes.
>
> Thanks,
>
> Stefan Miklosovic

Re: Debian repository intermittent outages

[Brandon Williams]

I created https://issues.apache.org/jira/browse/INFRA-25843 to have
this looked into.

Kind Regards,
Brandon

On Tue, Jun 4, 2024 at 8:03 AM Kornél Pál  wrote:
>
> Hi,
>
> The redirection at https://debian.cassandra.apache.org/dists/40x/Release is 
> very slow, sometimes even connection times out. This makes apt-get update 
> fail.
>
> I tried it from multiple locations.
>
> I don't see any issues with the jfrog site that is the redirection target, 
> but I would prefer to keep using the official repository URL.
>
> Could you please check if you are seeing any issues with the redirection site.
>
> Thank you,
> Kornel

Re: [DISCUSS] Stream Pipelines on hot paths

[Brandon Williams]

On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky  wrote:

> +1 to forbidding Stream usage entirely; the convenience of using them
> outside of hot paths is less than the burden of figuring out whether or not
> a particular path is hot.
>

I think I have most frequently appreciated them in tests, which I think we
could except, since these are categorically not in the hot path.

Kind Regards,
Brandon

Re: Updating Instaclustr donated Jenkins Agents

[Brandon Williams]

On Fri, May 24, 2024 at 9:07 AM Brandon Williams  wrote:
> I just want to note that this will reduce the x86 pool from 42 to 31,

Or more correctly, the pool will go from 42 to 33 x86 agents.

Kind Regards,
Brandon

Re: Updating Instaclustr donated Jenkins Agents

[Brandon Williams]

On Thu, May 23, 2024 at 5:51 PM Fleming, Jackson via dev
 wrote:
> Primarily this would be moving from x86 instances to Graviton ARM based ones, 
> as we’ve seen a pretty good uptake of ARM usage, and we’d like to help ensure 
> that there’s good testing coverage across both x86 and ARM architectures.

I just want to note that this will reduce the x86 pool from 42 to 31,
and then we will have a parallel pipeline of 9 ARM agents (15 if the
other 6 come back.)  Currently I think we have about an 8 hour
post-commit run time with 42 machines (though I'm sure there is room
for improvement.)

Also I'm going to update the agents page you linked shortly, but in
CASSANDRA-19241 we are upgrading all hosts to Ubuntu 22.04 and using
one single large partition for everything, so if you switch them
please keep that in mind.

Kind Regards,
Brandon

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, May 21, 2024 at 5:59 PM Bret McGuire  wrote:
>
>Greetings all!  We're going to give this another go.
>
>Apologies for the confusion that sprang out of our last attempt.  It 
> appears that the Nexus staging repository for the 4.18.1 release was 
> accidentally released shortly after it was created.  As a result Maven 
> artifacts for this release are already out in the wild, so this vote will be 
> a little unusual.  We'll be voting normally, but if the vote is successful 
> we'll simply leave the Maven artifacts exactly where they are.  If the vote 
> is unsuccessful these artifacts will be removed from Maven Central and we'll 
> try again with 4.18.2.
>
>Big thanks to mck and driftx for their help in untangling these issues.
>
>With all of that said let's get to it.  I’m proposing the test build of 
> Cassandra Java Driver 4.18.1 for release.
>
> sha1: cbdde2878786fa6c4077a21352cbe738875f2106
>
> Git: https://github.com/apache/cassandra-java-driver/tree/4.18.1
>
> Maven Artifacts: As discussed above
>
>
>The Source release and Binary convenience artifacts are available here:
>
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/4.18.1/
>
>
>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.
>
>One additional note: this is my first time doing a release of the Java 
> driver so if you're so inclined you can find my PGP key information in the 
> KEYS file.
>
>
>Thanks all!
>
>
>- Bret -

[RELEASE] Apache Cassandra 4.0.13 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.0.13.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 4.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now
https://debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/40x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-4.0.13/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 4.1.5 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.1.5.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 4.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now
https://debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/41x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-4.1.5/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [VOTE] Release Apache Cassandra 4.0.13

[Brandon Williams]

With five +1 (3 binding including my own) and no -1, the vote passes.
I'll get the artifacts published.

Kind Regards,
Brandon

On Thu, May 2, 2024 at 10:16 AM Brandon Williams  wrote:
>
> Proposing the test build of Cassandra 4.0.13 for release.
>
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
>
> Kind Regards,
> Brandon

Re: [VOTE] Release Apache Cassandra 4.1.5

[Brandon Williams]

With five +1 (4 binding including my own) and no -1, the vote passes.
I'll get the artifacts published.

On Thu, May 2, 2024 at 11:36 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.5 for release.
>
> sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
> Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.5

[Brandon Williams]

Friendly reminder that this vote is still open and lacks one binding
vote to pass.

On Thu, May 2, 2024 at 11:36 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.5 for release.
>
> sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
> Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.13

[Brandon Williams]

Friendly reminder that this vote is still open and needs two more binding votes.

Kind Regards,
Brandon

On Thu, May 2, 2024 at 10:16 AM Brandon Williams  wrote:
>
> Proposing the test build of Cassandra 4.0.13 for release.
>
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
>
> Kind Regards,
> Brandon

Re: [VOTE] Release Apache Cassandra 4.1.5

[Brandon Williams]

+1

On Thu, May 2, 2024 at 11:36 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.5 for release.
>
> sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
> Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.13

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, May 2, 2024 at 10:16 AM Brandon Williams  wrote:
>
> Proposing the test build of Cassandra 4.0.13 for release.
>
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
>
> Kind Regards,
> Brandon

Re: Joining the Slack

[Brandon Williams]

Hi Raymond,

I've sent you an invite.

Kind Regards,
Brandon

On Tue, May 7, 2024 at 1:41 PM Raymond Welgosh  wrote:
>
> Hi,
>
> My name is Raymond Welgosh. I previously emailed the owner so if this was 
> resolved please ignore. I am interested in joining the AFS slack. Please let 
> me know what steps I should take. Thank you!
>
> Sincerely,
> Raymond W.

[VOTE] Release Apache Cassandra 4.1.5

[Brandon Williams]

Proposing the test build of Cassandra 4.1.5 for release.

sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt
[2]: NEWS.txt: https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt

[VOTE] Release Apache Cassandra 4.0.13

[Brandon Williams]

Proposing the test build of Cassandra 4.0.13 for release.

sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt

Kind Regards,
Brandon

Re: [DISCUSS] Donating easy-cass-stress to the project

[Brandon Williams]

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 want to drag ECS back to ant, but I also
don't want two different build systems in-tree.

Kind Regards,
Brandon

On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>
> 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 
> umbrella.
>
> My goal with the project was always to provide something that's easy to use.  
> Up and running in a couple minutes, using the parameters to shape the 
> workload rather than defining everything through configuration.  I was happy 
> to make this tradeoff since Cassandra doesn't have very many types of queries 
> and it's worked well for me over the years.
>
> Obviously I would continue working on this project, and I hope this would 
> encourage others to contribute.  I've heard a lot of good ideas that other 
> teams have implemented in their folks.  I'd love to see those ideas make it 
> into the project, and it sounds like it would be a lot easier for teams to 
> get approval to contribute if it was under the project umbrella.
>
> Would love to hear your thoughts.
>
> Thanks,
> Jon
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> [2] https://github.com/rustyrazorblade/easy-cass-stress

Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

[Brandon Williams]

Congrats everyone!

Kind Regards,
Brandon

On Wed, Apr 17, 2024 at 12:11 PM Benjamin Lerer  wrote:
>
> The Apache Cassandra PMC is pleased to announce that Alexandre Dutra, Andrew 
> Tolbert, Bret McGuire and Olivier Michallat have accepted the invitation to 
> become committers on the java driver sub-project.
>
> Thanks for your contributions to the Java driver during all those years!
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

[RELEASE] Apache Cassandra 3.11.17 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.11.17.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now https:/
/debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/311x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-3.11.17/CHANGES.txt
[2]: NEWS.txt 
https://github.com/apache/cassandra/blob/cassandra-3.11.17/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [RESULT] [VOTE] Release Apache Cassandra 3.11.17

[Brandon Williams]

Minor correction, three votes were binding.

On Tue, Apr 16, 2024 at 7:08 AM Brandon Williams
 wrote:
>
> On Fri, Apr 12, 2024 at 1:52 PM Brandon Williams
>  wrote:
> > 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.
>
> The vote passes with five +1s (four binding).  I'll get the artifacts 
> published.
>
> Kind Regards,
> Brandon

[RESULT] [VOTE] Release Apache Cassandra 3.11.17

[Brandon Williams]

On Fri, Apr 12, 2024 at 1:52 PM Brandon Williams
 wrote:
> 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.

The vote passes with five +1s (four binding).  I'll get the artifacts published.

Kind Regards,
Brandon

[RELEASE] Apache Cassandra 3.0.30 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.30.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now https:/
/debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/30x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-3.0.30/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-3.0.30/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RESULT] [VOTE] Release Apache Cassandra 3.0.30

[Brandon Williams]

On Thu, Apr 11, 2024 at 1:48 PM Brandon Williams
 wrote:
> 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.

The vote passes with three +1s (three binding.)  I will publish the artifacts.

Kind Regards,
Brandon

[VOTE] Release Apache Cassandra 3.11.17

[Brandon Williams]

Proposing the test build of Cassandra 3.11.17 for release.

sha1: d079952c50019c3c8c96e341a01f7bc0554e1733
Git: https://github.com/apache/cassandra/tree/3.11.17-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1327/org/apache/cassandra/cassandra-all/3.11.17/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.11.17/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/3.11.17-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/3.11.17-tentative/NEWS.txt

[VOTE] Release Apache Cassandra 3.0.30

[Brandon Williams]

Proposing the test build of Cassandra 3.0.30 for release.

sha1: 657e595b78227c28a6b8808ef9bf62f646029f3b
Git: https://github.com/apache/cassandra/tree/3.0.30-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1326/org/apache/cassandra/cassandra-all/3.0.30/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.0.30/

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]: CHANGES.txt:
https://github.com/apache/cassandra/blob/3.0.30-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/3.0.30-tentative/NEWS.txt

Re: [DISCUSS] Modeling JIRA fix version for subprojects

[Brandon Williams]

I am +1 on separate projects as well, but to Abe's point I don't think
it matters now, we had 21 binding votes for CEP-8 which spells this
out.

Kind Regards,
Brandon

On Tue, Apr 9, 2024 at 9:24 AM Josh McKenzie  wrote:
>
> +1 to separate JIRA projects per subproject. Having workflows distinct to 
> each project is reason enough for me, nevermind the global namespace 
> pollution that occurs if you pack a bunch of disparate projects together into 
> one instance.
>
> On Mon, Apr 8, 2024, at 9:11 PM, Dinesh Joshi wrote:
>
> hi folks - sorry to have dropped the ball on responding to this thread.
>
> My 2 cents are as follows -
>
> 1. Having a separate JIRA project for each sub-project will add management 
> overhead. This option, however, allows us to model unique workflows for the 
> sub-project.
>
> 2. Managing the sub-project as part of the Cassandra JIRA project would imply 
> less management overhead but the sub-project would need to conform to the 
> same workflows.
>
> I would pick option 1 unless there is a strong reason and desire to manage a 
> separate Jira project. We can always split out the Java Driver project if 
> things don't work out. OTOH merging a Jira project is harder.
>
> Thanks,
>
> Dinesh
>
> On Thu, Apr 4, 2024 at 12:45 PM Abe Ratnofsky  wrote:
>
> CEP-8 proposes using separate Jira projects per Cassandra sub-project:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>
> > We suggest distinct Jira projects, one per driver, all to be created.
>
> I don't see any discussion changing that from the [DISCUSS] or vote threads:
> https://lists.apache.org/thread/01pljcncyjyo467l5orh8nf9okrh7oxm
> https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
> https://lists.apache.org/thread/crolkrhd4y6tt3k4hsy204xomshlcp4p
>
> But looks like upon acceptance that was changed:
> https://lists.apache.org/thread/dhov01s8dvvh3882oxhkmmfv4tqdd68o
>
> > New issues will be tracked under the CASSANDRA project on Apache’s JIRA 
> >  under the component 
> > ‘Client/java-driver’.
>
> I'm in favor of using the same Jira as Cassandra proper. Committership is 
> project-wide, so having a standardized process (same ticket flow, review 
> rules, labels, etc. is beneficial). But multiple votes happened based on the 
> content of the CEP, so we should stick to what was voted on and move to a 
> separate Jira.
>
> --
> Abe
>
>

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

[Brandon Williams]

Given that 3.6 has been EOL for 2+ years[1], I don't think it makes
sense to add support for it back.

Kind Regards,
Brandon

[1] https://devguide.python.org/versions/

On Mon, Mar 11, 2024 at 12:08 PM David Capwell  wrote:
>
> Originally we had planned to support RHEL 7 but in testing 5.0 we found out 
> that cqlsh no longer works on RHEL 7[1].  This was changed in CASSANDRA-19245 
> which upgraded python-driver from 3.28.0 to 3.29.0. For some reason this 
> minor version upgrade also dropped support for python 3.6 which is the 
> supported python version on RHEL 7.
>
> We wanted to bring this to the attention of the community to figure out next 
> steps; do we wish to say that RHEL 7 is no longer supported (making upgrades 
> tied to OS upgrades, which can be very hard for users), or do we want to add 
> python 3.6 support back to python-driver?
>
>
> 1: the error seen by users is
> $ cqlsh
> Warning: unsupported version of Python, required 3.8-3.11 but found 3.6 
> Warning: unsupported version of Python, required 3.8-3.11 but found 2.7
> No appropriate Python interpreter found.
> $
>
>

Re: Welcome Brad Schoening as Cassandra Committer

[Brandon Williams]

Congrats Brad!

Kind Regards,
Brandon

On Wed, Feb 21, 2024 at 2:46 PM Josh McKenzie  wrote:
>
> The Apache Cassandra PMC is pleased to announce that Brad Schoening has 
> accepted
> the invitation to become a committer.
>
> Your work on the integrated python driver, launch script environment, and 
> tests
> has been a big help to many. Congratulations and welcome!
>
> The Apache Cassandra PMC members

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

[Brandon Williams]

I don't think there is as simple a way to identify those since there
are many ways you can specify a single token.

Kind Regards,
Brandon



On Thu, Feb 15, 2024 at 11:45 AM Jacek Lewandowski
 wrote:
>
> Brandon, that should be doable with the current filters I think - that is, 
> select only those tests which do not support vnodes. Do you know about such 
> in-jvm dtests as well?
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 15 lut 2024 o 18:21 Brandon Williams  napisał(a):
>>
>> On Thu, Feb 15, 2024 at 1:10 AM Jacek Lewandowski
>>  wrote:
>> > For dtests we have vnodes/no-vnodes, offheap/onheap, and nothing about 
>> > other stuff. To me running no-vnodes makes no sense because no-vnodes is 
>> > just a special case of vnodes=1. On the other hand offheap/onheap buffers 
>> > could be tested in unit tests. In short, I'd run dtests only with the 
>> > default and latest configuration.
>>
>> I largely agree that no-vnodes isn't useful, but there are some
>> non-vnode operations like moving a token that don't work with vnodes
>> and still need to be tested.  I think we could probably get quick
>> savings by breaking out the @no_vnodes tests to a separate suite run
>> so we aren't completely doubling our effort for little gain with every
>> commit.

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

[Brandon Williams]

On Thu, Feb 15, 2024 at 1:10 AM Jacek Lewandowski
 wrote:
> For dtests we have vnodes/no-vnodes, offheap/onheap, and nothing about other 
> stuff. To me running no-vnodes makes no sense because no-vnodes is just a 
> special case of vnodes=1. On the other hand offheap/onheap buffers could be 
> tested in unit tests. In short, I'd run dtests only with the default and 
> latest configuration.

I largely agree that no-vnodes isn't useful, but there are some
non-vnode operations like moving a token that don't work with vnodes
and still need to be tested.  I think we could probably get quick
savings by breaking out the @no_vnodes tests to a separate suite run
so we aren't completely doubling our effort for little gain with every
commit.

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

[Brandon Williams]

On Tue, Feb 13, 2024 at 6:17 AM Sam Tunnicliffe  wrote:
> Also, if CASSANDRA-16999 is only going to trunk, why can't we just deprecate 
> dual ports in 5.0 (as it isn't at -rc stage yet) and remove it from trunk? 
> That seems preferable to shoehorning something into the new 
> system_views.peers table, which isn't going to help any existing drivers 
> anyway as none of them will be using it.

I agree and I think it will be a mess having the port in 3.x, then not
in 4.0, 4.1, or 5.0, then resurrected again after that.

Kind Regards,
Brandon

Re: [VOTE] Release Apache Cassandra 4.1.4

[Brandon Williams]

I think we lost track of this one over some concern about
CASSANDRA-19097, but that turned out to be a test problem.  +1

Kind Regards,
Brandon

On Fri, Jan 26, 2024 at 4:31 AM Štefan Miklošovič
 wrote:
>
> Proposing the test build of Cassandra 4.1.4 for release.
>
> sha1: 99d9faeef57c9cf5240d11eac9db5b283e45a4f9
> Git: https://github.com/apache/cassandra/tree/4.1.4-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1324/org/apache/cassandra/cassandra-all/4.1.4/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.4/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.1.4-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.4-tentative/NEWS.txt

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Brandon Williams]

That's right, I'd forgotten about this.  I change my +1 to -1, there's not
enough value in this to break signatures.

Kind Regards,
Brandon


On Mon, Jan 22, 2024 at 12:42 PM Jeremiah Jordan 
wrote:

> Here was the thread where it was removed:
> lists.apache.org
> <https://lists.apache.org/thread/9wtw9m4r858xdm78krf1z74q3krc27st>
> [image: favicon.ico]
> <https://lists.apache.org/thread/9wtw9m4r858xdm78krf1z74q3krc27st>
> <https://lists.apache.org/thread/9wtw9m4r858xdm78krf1z74q3krc27st>
>
>
> On Jan 22, 2024, at 12:37 PM, J. D. Jordan 
> wrote:
>
> I think we used to have this and removed them because it was breaking
> the encryption signature on messages or something which meant they were
> very likely to be treated as spam?
>
> Not saying we can’t put it back on, but it was removed for good reasons
> from what I recall.
>
> On Jan 22, 2024, at 12:19 PM, Brandon Williams  wrote:
>
>
> +1
>
>
> Kind Regards,
>
> Brandon
>
>
> On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas 
> wrote:
>
>
> Hi all,
>
>
> I'd like to propose appending the following two footers to messages sent
> to the user@ and dev@ lists. The proposed postscript including line
> breaks is between the "X" blocks below.
>
>
> User List Footer:
>
> X
>
>
> ---
>
> Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org.
> Do not reply to this message.
>
> Cassandra Community: Follow other mailing lists or join us in Slack:
> https://cassandra.apache.org/_/community.html
>
> X
>
>
> Dev List Footer:
>
> X
>
>
> ---
>
> Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org.
> Do not reply to this message.
>
> Cassandra Community: Follow other mailing lists or join us in Slack:
> https://cassandra.apache.org/_/community.html
>
> X
>
>
> Offering this proposal for three reasons:
>
> – Many users are sending "Unsubscribe" messages to the full mailing list
> which prompts others to wish to unsubscribe – a negative cascade that
> affects the size of our user community.
>
> – Many users don't know where to go to figure out how to unsubscribe,
> especially if they'd joined many years ago.
>
> – Nearly all mailing lists provide a one-click mechanism for unsubscribing
> or built-in mail client integration to do so via message headers. Including
> compact instructions on how to leave is valuable to subscribers.
>
>
> #asfinfra indicates that such footers can be appended given project
> consensus and an INFRA- ticket:
> https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079
>
>
> If we reach consensus on adding a message footer, I'll file an INFRA
> ticket with a link to this thread.
>
>
> Thanks,
>
>
> – Scott
>
>
>


favicon.ico
Description: Binary data

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas  wrote:
>
> Hi all,
>
> I'd like to propose appending the following two footers to messages sent to 
> the user@ and dev@ lists. The proposed postscript including line breaks is 
> between the "X" blocks below.
>
> User List Footer:
> X
>
> ---
> Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org. Do 
> not reply to this message.
> Cassandra Community: Follow other mailing lists or join us in Slack: 
> https://cassandra.apache.org/_/community.html
> X
>
> Dev List Footer:
> X
>
> ---
> Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org. Do 
> not reply to this message.
> Cassandra Community: Follow other mailing lists or join us in Slack: 
> https://cassandra.apache.org/_/community.html
> X
>
> Offering this proposal for three reasons:
> – Many users are sending "Unsubscribe" messages to the full mailing list 
> which prompts others to wish to unsubscribe – a negative cascade that affects 
> the size of our user community.
> – Many users don't know where to go to figure out how to unsubscribe, 
> especially if they'd joined many years ago.
> – Nearly all mailing lists provide a one-click mechanism for unsubscribing or 
> built-in mail client integration to do so via message headers. Including 
> compact instructions on how to leave is valuable to subscribers.
>
> #asfinfra indicates that such footers can be appended given project consensus 
> and an INFRA- ticket: 
> https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079
>
> If we reach consensus on adding a message footer, I'll file an INFRA ticket 
> with a link to this thread.
>
> Thanks,
>
> – Scott
>

Re: [VOTE] Release Apache Cassandra 4.0.12

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Jan 18, 2024 at 5:56 AM Štefan Miklošovič
 wrote:
>
> Proposing the test build of Cassandra 4.0.12 for release.
>
> sha1: af752fcd535ccdac69b9fed88047b2dd7625801e
> Git: https://github.com/apache/cassandra/tree/4.0.12-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1323/org/apache/cassandra/cassandra-all/4.0.12/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.12/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.0.12-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.12-tentative/NEWS.txt

Re: [Discuss] CQLSH should left-align numbers, right-align text (CASSANDRA-19150)

[Brandon Williams]

A configuration option for a cosmetic feature seems like overkill to me, I
don't think which side we align text on is enough to justify (heh) the
overhead.  I agree with how Excel and Postgres do it and think we should
follow suit.

Kind Regards,
Brandon


On Tue, Jan 9, 2024 at 9:19 AM Brad  wrote:

> Derek,
>
> I'm proposing a switch or blanket change to a convention of right aligned
> text and left aligned numbers in CQLSH.
>
> I took a look at two other examples, Excel and Postgres shell and that's
> how they work when displaying tabular data.  The Jira was originally to
> make right or left alignment an option, but making it configurable seems
> less useful than choosing a better standard.
>
> On Tue, Jan 9, 2024 at 9:58 AM Derek Chen-Becker 
> wrote:
>
>> Just to clarify, per the ticket you're proposing a configuration option
>> to control this on a per-column basis, correct? Your email makes it sound
>> like a blanket change.
>>
>> Cheers,
>>
>> Derek
>>
>> On Tue, Jan 9, 2024 at 7:34 AM Brad  wrote:
>>
>>> CQLSH currently left-aligns all output, affecting both numbers and
>>> text.  While this works well for numbers, a better approach adopted by many
>>> is to left align numbers and right align text.
>>>
>>> For example, both Excel and Postgres shell use the later:
>>>
>>> psql
>>>
>>> # select * from employee;
>>>
>>>  empid |  name   |dept
>>>
>>> ---+-+
>>>
>>>  1 | Clark   | Sales
>>>
>>>200 | Dave| Accounting
>>>
>>> 33 | Johnson | Sales
>>>
>>>
>>> while CQLSH simply left aligns all the columns
>>>
>>> cqlsh> select * from employee;
>>>
>>>  empid | dept   | name
>>>
>>> ---++-
>>>
>>> 33 |  Sales | Johnson
>>>
>>>  1 |  Sales |   Clark
>>>
>>>200 | Accounting |Dave
>>>
>>>
>>>
>>> Left aligned text looks much worse on text values which share common
>>> prefixes
>>>
>>>
>>> cqlsh> select * from system_views.system_properties limit 7 ;
>>>
>>>
>>>  name   | value
>>>
>>>
>>> +
>>>
>>>   JAVA_HOME |
>>>   /Users/brad/.jenv/versions/17
>>>
>>>cassandra.jmx.local.port |
>>> 7199
>>>
>>>cassandra.logdir |
>>> /usr/local/cassandra-5.0-beta1/bin/../logs
>>>
>>>cassandra.storagedir |
>>> /usr/local/cassandra-5.0-beta1/bin/../data
>>>
>>>   com.sun.management.jmxremote.authenticate |
>>>   false
>>>
>>>  com.sun.management.jmxremote.password.file |
>>>   /etc/cassandra/jmxremote.password
>>>
>>> io.netty.transport.estimateSizeOnSubmit |
>>>   false
>>>
>>>
>>>
>>> The Jira CASSANDRA-19150
>>>  discusses this
>>> in further detail with some additional examples.
>>>
>>>
>>> I wanted to raise the issue here to propose changing CQLSH to
>>> right-align text while continue to left-align numbers.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Brad Schoening
>>>
>>>
>>> ReplyForward
>>> Add reaction
>>>
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>>
>>

Re: Welcome Maxim Muzafarov as Cassandra Committer

[Brandon Williams]

Congrats Maxim!

Kind Regards,
Brandon

On Mon, Jan 8, 2024 at 12:20 PM Josh McKenzie  wrote:
>
> The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has 
> accepted
> the invitation to become a committer.
>
> Thanks for all the hard work and collaboration on the project thus far, and 
> we're all looking forward to working more with you in the future. 
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>
>

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

[Brandon Williams]

+1

Kind Regards,
Brandon

On Sat, Dec 9, 2023 at 1:43 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra Java Driver 4.18.0 for release.
>
> sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9
> Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1322
>
> The Source release and Binary convenience artifacts are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/4.18.0/
>
> This is the first release post-donation of the Java Driver.  The maven 
> coordinates have changed from com.datastax.oss to org.apache.cassandra, while 
> all package names remain the same.  There is still work to be done on a 
> number of fronts, e.g. being vendor-neutrality, covered under CASSANDRA-18611.
>
> 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.
>
>

Re: Welcome Mike Adamson as Cassandra committer

[Brandon Williams]

Congratulations Mike!

Kind Regards,
Brandon

On Fri, Dec 8, 2023 at 8:41 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Mike Adamson has accepted
> the invitation to become committer.
>
> Thanks a lot, Mike, for everything you have done for the project.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Brandon Williams]

On Thu, Dec 7, 2023 at 8:50 AM Alex Petrov  wrote:
> > I've noticed many "sleeps" in the tests - is it possible with simulation 
> > tests to artificially move the clock forward by, say, 5 seconds instead of 
> > sleeping just to test, for example whether TTL works?)
>
> Yes, simulator will skip the sleep and do a simulated sleep with a simulated 
> clock instead.

Since it uses an artificial clock, does this mean that the simulator
is also impervious to timeouts caused by the underlying environment?

Kind Regards,
Brandon

Re: [DISCUSS] CASSANDRA-19104: Standardize tablestats formatting and data units

[Brandon Williams]

Given how fundamental disk space is to operational competence, it's
hard to imagine anyone actually parsing this output instead of using
at least something like the machine readable option.  The switch is
rather simple if they need to make it, and they will be better for it,
so I support tidying up this output so new users have a better
experience.

Kind Regards,
Brandon

On Mon, Dec 4, 2023 at 8:44 AM Brad  wrote:
>
> Tablestats currently reports output in a mixed format which is neither ideal 
> for human readability nor machine readability.  Spaces are also 
> inconsistently used and 13 digit numbers w/out commas or larger units are 
> complicated to read.
>
> For example, 'Bytes repaired / un-repaired / pending' uses KiB, MiB units, 
> but 'Space used live / total' uses bytes.
>
> Space used (live): 1463210998523
> Space used (total): 1463210998523
>
> Bytes repaired: 0.000KiB
> Bytes unrepaired: 4315.386GiB
> Bytes pending repair: 0.000KiB
>
> Given tablestats supports a machine readable formatting with the -f format 
> option for json or yaml output, this Jira proposes:
>
> standardizing the output to be human readable (-H) as default and
> eliminating the current mixed mode of formatting.
>
> The above example would become:
>
> Space used (live): 1463.210 GiB
> Space used (total): 1463.210 GiB
>
> Bytes repaired: 0.000 KiB
> Bytes unrepaired: 4315.386 GiB
> Bytes pending repair: 0.000 KiB
>
> Existing machine readable formatting (with -f) will be unchanged.  More 
> detailed examples can be found in the Jira CASSANDRA-19104 and associated 
> google spreadsheet detailing the existing and proposed output:  
> https://tinyurl.com/38edebjd
>
> We welcome feedback and thoughts on this.
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Fri, 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.apache.org/content/repositories/orgapachecassandra-1321/org/apache/cassandra/cassandra-all/5.0-beta1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-beta1/
>
> 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]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0-beta1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-beta1-tentative/NEWS.txt

Re: [VOTE] Release Harry 0.0.2

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov  wrote:
>
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking.
>
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
>
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
> Prominent changes:
>
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
>
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
>
> The vote will be open for 24 hours. 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.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

So then cutting an alpha2 is possible.

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 2:59 PM Mick Semb Wever  wrote:
>
>
> You can't change bits in a signed and checksummed artefact.  You have to cut 
> from scratch.
>
> On Tue, 28 Nov 2023 at 20:28, Brandon Williams  wrote:
>>
>> I think the last time I looked into it there was nothing in the
>> scripts that forced anything, but if that's not true I think we should
>> be fixing that, not having it drive our release decisions.
>>
>> Kind Regards,
>> Brandon
>>
>> On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever  wrote:
>> >
>> >
>> >
>> > On Tue, 28 Nov 2023 at 19:27, J. D. Jordan  
>> > wrote:
>> >>
>> >> That said. This is clearly better than and with many fixes from the 
>> >> alpha. Would people be more comfortable if this cut was released as 
>> >> another alpha and we do beta1 once the known fixes land?
>> >
>> >
>> >
>> > There is no way with our release process to do this.  The QA label is part 
>> > of our version number and that's baked in.
>> >
>> > Otherwise I entirely agree that alpha2 would have been the better label 
>> > here.  We are working in an unusual situation, one I hope we don't repeat.
>> >

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

I think the last time I looked into it there was nothing in the
scripts that forced anything, but if that's not true I think we should
be fixing that, not having it drive our release decisions.

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever  wrote:
>
>
>
> On Tue, 28 Nov 2023 at 19:27, J. D. Jordan  wrote:
>>
>> That said. This is clearly better than and with many fixes from the alpha. 
>> Would people be more comfortable if this cut was released as another alpha 
>> and we do beta1 once the known fixes land?
>
>
>
> There is no way with our release process to do this.  The QA label is part of 
> our version number and that's baked in.
>
> Otherwise I entirely agree that alpha2 would have been the better label here. 
>  We are working in an unusual situation, one I hope we don't repeat.
>

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Brandon Williams]

Congrats Francisco!

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 12:53 PM Dinesh Joshi  wrote:
>
> The PMC members are pleased to announce that Francisco Guerrero Hernandez has 
> accepted
> the invitation to become committer today.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

If we are going to commit to beta2 before the summit because "putting
a beta w/ SAI in this state into users’ hands at summit would be very,
very bad" I don't see why we need to have a subpar beta1 at all?

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 11:16 AM Mick Semb Wever  wrote:
>
>
>
> On Tue, 28 Nov 2023 at 18:06, Caleb Rackliffe  
> wrote:
>>
>> Just to update this thread, Mike has identified the root cause of 19011 and 
>> in the process uncovered 2 additional very closely related issues. 
>> (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and 
>> he continues to test.
>>
>> After some conversation w/ Mick, Alex, and Mike, I feel like cutting a beta1 
>> now is fine as long as we commit to a beta2 before summit that includes 
>> 19011. Putting a beta w/ SAI in this state into users’ hands at summit would 
>> be very, very bad.
>
>
>
> In case this sounds weird, to clarify:  this is a mitigation action – there's 
> a risk with every release that it does not make it through.  beta1 might not 
> be great for SAI, but getting it out is better than having only alpha1 
> available come Summit.  It might feel odd to have a beta2 right after a 
> beta1, but I don't mind (and would rather) take the time and investment.
>
> beta1 would be announced with an appropriate disclaimer.
>
>

Re: Request to create a Jira account

[Brandon Williams]

You should hopefully have your account now, welcome to Apache
Cassandra, Rajneesh!

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 4:30 PM Rajneesh  wrote:
>
> Thank you, Brandon!
>
> -Regards
>
>
> On Mon, Nov 27, 2023 at 1:34 PM Brandon Williams  wrote:
>>
>> Please request one here: https://selfserve.apache.org/jira-account.html
>>
>> Kind Regards,
>> Brandon
>>
>> On Mon, Nov 27, 2023 at 3:29 PM Rajneesh  wrote:
>> >
>> > Hi,
>> >
>> > I am looking to contribute to Cassandra.
>> >
>> > I am going through the How-To here - 
>> > https://cassandra.apache.org/_/development/index.html
>> >
>> > Following what is mentioned in the above guide, I'm planning to start from 
>> > the Low Hanging Fruit.
>> >
>> > May I please have a Jira account?
>> >
>> > - Regards

Re: Request to create a Jira account

[Brandon Williams]

Please request one here: https://selfserve.apache.org/jira-account.html

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 3:29 PM Rajneesh  wrote:
>
> Hi,
>
> I am looking to contribute to Cassandra.
>
> I am going through the How-To here - 
> https://cassandra.apache.org/_/development/index.html
>
> Following what is mentioned in the above guide, I'm planning to start from 
> the Low Hanging Fruit.
>
> May I please have a Jira account?
>
> - Regards

Re: [DISCUSS] Harry in-tree

[Brandon Williams]

I am +1 on including Harry in-tree.

Kind Regards,
Brandon

On Fri, Nov 24, 2023 at 9:44 AM Alex Petrov  wrote:
>
> Hi everyone,
>
> With TCM landed, there will be way more Harry tests in-tree: we are using it 
> for many coordination tests, and there's now a simulator test that uses 
> Harry. During development, Harry has allowed us to uncover and resolve 
> numerous elusive edge cases.
>
> I had conversations with several folks, and wanted to propose to move 
> harry-core to Cassandra test tree. This will substantially 
> simplify/streamline co-development of Cassandra and Harry. With a new 
> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
> will also be much more approachable.
>
> Besides making it easier for everyone to develop new fuzz tests, it will also 
> substantially lower the barrier to entry. Currently, debugging an issue found 
> by Harry involves a cumbersome process of rebuilding and transferring jars 
> between Cassandra and Harry, depending on which side you modify. This not 
> only hampers efficiency but also deters broader adoption. By merging 
> harry-core into the Cassandra test tree, we eliminate this barrier.
>
> Thank you,
> --Alex
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

On Mon, Nov 27, 2023 at 9:25 AM Mick Semb Wever  wrote:
>
> It was agreed to move them to 5.0-rc

Where?

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

[Brandon Williams]

As long as it's disabled by default that's an easy +1 from me.

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 7:03 AM Jacek Lewandowski
 wrote:
>
> Hey,
>
> I'd like to ask if we can include 
> https://issues.apache.org/jira/browse/CASSANDRA-18464 in the 5.0-beta1 
> release. This introduces the ability to write to the commitlog using direct 
> I/O and bringing some noticeable performance improvements when enabled 
> (disabled by default).
>
> Since it introduces a change in the yaml config, it probably cannot be 
> delivered in RC or 5.0.x - hence my question.
>
> The ticket has been reviewed and tested. It is basically in the 
> read-to-commit state.
>
> thanks,
> Jacek
>

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

[Brandon Williams]

I agree and just now opened it for 5.0-beta (among others.)

Kind Regards,
Brandon

On Sat, Nov 4, 2023 at 11:08 AM Benedict  wrote:
>
> I think before we cut a beta we need to have diagnosed and fixed 18993 
> (assuming it is a bug).
>
> > On 4 Nov 2023, at 16:04, Mick Semb Wever  wrote:
> >
> > 
> >>
> >> With the publication of this release I would like to switch the
> >> default 'latest' docs on the website from 4.1 to 5.0.  Are there any
> >> objections to this ?
> >
> >
> > I would also like to propose the next 5.0 release to be 5.0-beta1
> >
> > With the aim of reaching GA for the Summit, I would like to suggest we
> > work towards the best-case scenario of 5.0-beta1 in two weeks and
> > 5.0-rc1 first week Dec.
> >
> > I know this is a huge ask with lots of unknowns we can't actually
> > commit to.  But I believe it is a worthy goal, and possible if nothing
> > sideswipes us – but we'll need all the help we can get this month to
> > make it happen.
>

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Oct 30, 2023 at 4:47 PM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 5.0-alpha2 for release.
>
> DISCLAIMER, this alpha release does not contain the features:
> Transactional Cluster Metadata (CEP-21) and Accord Transactions
> (CEP-15).  These features are under discussion to be pushed to a
> 5.1-alpha1 release, with an eta still this year.
>
> This release does contain Vector Similarity Search (CEP-30).
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: ea76d148c374198fede6978422895668857a927f
> Git: https://github.com/apache/cassandra/tree/5.0-alpha2-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1317/org/apache/cassandra/cassandra-all/5.0-alpha2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha2/
>
> 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]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha2-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-alpha2-tentative/NEWS.txt

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Brandon Williams]

, my point of view is changing.
>>
>>
>> Josh's point about what's best for users is crucial. Users deserve stable
>>
>> code with a regular cadence of features that make their lives easier. If we
>>
>> put 5.0 on hold for TCM + Accord, users will get neither for a very long
>>
>> time. And I mentioned a disaster yesterday. A bigger disaster would be
>>
>> shipping Accord with a major bug that causes data loss, eroding community
>>
>> trust. Accord has to be the most bulletproof of all bulletproof features.
>>
>> The pressure to ship is only going to increase and that's fertile ground
>>
>> for that sort of bug.
>>
>>
>> So, taking a step back and with a clearer picture, I support the 5.0 + 5.1
>>
>> plan mainly because I don't think 5.1 is (or should be) a fast follow.
>>
>>
>> For the user community, the communication should be straightforward. TCM +
>>
>> Accord are turning out to be much more complicated than was originally
>>
>> scoped, and for good reasons. Our first principle is to provide a stable
>>
>> and reliable system, so as a result, we'll be de-coupling TCM + Accord from
>>
>> 5.0 into a 5.1 branch, which is available in parallel to 5.0 while
>>
>> additional hardening and testing is done. We can communicate this in a blog
>>
>> post.,
>>
>>
>> To make this much more palatable to our use community, if we can get a
>>
>> build and docker image available ASAP with Accord, it will allow developers
>>
>> to start playing with the syntax. Up to this point, that hasn't been widely
>>
>> available unless you compile the code yourself. Developers need to
>>
>> understand how this will work in an application, and up to this point, the
>>
>> syntax is text they see in my slides. We need to get some hands-on and that
>>
>> will get our user community engaged on Accord this calendar year. The
>>
>> feedback may even uncover some critical changes we'll need to make. Lack of
>>
>> access to Accord by developers is a critical problem we can fix soon and
>>
>> there will be plenty of excitement there and start building use cases
>>
>> before the final code ships.
>>
>>
>> I'm bummed but realistic. It sucks that I won't have a pony for Christmas,
>>
>> but maybe one for my birthday?
>>
>>
>> Patrick
>>
>>
>>
>>
>> On Tue, Oct 24, 2023 at 7:23 AM Josh McKenzie  wrote:
>>
>>
>> > Maybe it won't be a glamorous release but shipping
>>
>> > 5.0 mitigates our worst case scenario.
>>
>> >
>>
>> > I disagree with this characterization of 5.0 personally. UCS, SAI, Trie
>>
>> > memtables and sstables, maybe vector ANN if the sub-tasks on C-18715 are
>>
>> > accurate, all combine to make 5.0 a pretty glamorous release IMO
>>
>> > independent of TCM and Accord. Accord is a true paradigm-shift game-changer
>>
>> > so it's easy to think of 5.0 as uneventful in comparison, and TCM helps
>>
>> > resolve one of the biggest pain-points in our system for over a decade, but
>>
>> > I think 5.0 is a very meaty release in its own right today.
>>
>> >
>>
>> > Anyway - I agree with you Brandon re: timelines. If things take longer
>>
>> > than we'd hope (which, if I think back, they do roughly 100% of the time on
>>
>> > this project), blocking on these features could both lead to a significant
>>
>> > delay in 5.0 going out as well as increasing pressure and risk of burnout
>>
>> > on the folks working on it. While I believe we all need some balanced
>>
>> > urgency to do our best work, being under the gun for something with a hard
>>
>> > deadline or having an entire project drag along blocked on you is not where
>>
>> > I want any of us to be.
>>
>> >
>>
>> > Part of why we talked about going to primarily annual calendar-based
>>
>> > releases was to avoid precisely this situation, where something that
>>
>> > *feels* right at the cusp of merging leads us to delay a release
>>
>> > repeatedly. We discussed this a couple times this year:
>>
>> > 1: https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3,
>>
>> > where Mick proposed a "soft-freeze" for everything w/out exception and 1st
>>
>> > week October "hard-fr

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai  wrote:
>
> Hi,
>
> I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to trunk 
> and hope we are all OK with it.
>
> In CASSANDRA-18941, I am adding the capability to produce size-bounded 
> SSTables in CQLSSTableWriter for sorted data. It can greatly benefit 
> Cassandra Analytics (https://github.com/apache/cassandra-analytics) for bulk 
> writing SSTables, since it avoids buffering and sorting on flush, given the 
> data source is sorted already in the bulk write process. Cassandra Analytics 
> supports Cassandra 4.0 and depends on the cassandra-all 4.0.x library. 
> Therefore, we are mostly interested in using the new capability in 4.0.
>
> CQLSSTableWriter is only used in offline tools and never in the code path of 
> Cassandra server.
>
> Any objections to merging the patch to 4.0 and up to trunk?
>
> - Yifan

Re: CASSANDRA-16565

[Brandon Williams]

On Tue, Oct 24, 2023 at 7:48 AM Claude Warren, Jr via dev
 wrote:
>
> Is there someplace I can stash the tgz that others can download it from? The 
> file info is : 6269066 okt 24 12:46 compare_oshi_sigar.tgz

Is posting a github branch not sufficient?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Brandon Williams]

The concern I have with this is that is a big slippery 'if' that
involves development time estimation, and if it tends to take longer
than we estimate (as these things tend to do), then I can see a future
where 5.0 is delayed until the middle of 2024, and I really don't want
that to happen.  Maybe it won't be a glamorous release but shipping
5.0 mitigates our worst case scenario.

Kind Regards,
Brandon

On Mon, Oct 23, 2023 at 4:02 PM Dinesh Joshi  wrote:
>
> I have a strong preference to move out the 5.0 date to have accord and TCM. I 
> don’t see the point in shipping 5.0 without these features especially if 5.1 
> is going to follow close behind it.
>
> Dinesh
>
> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever  wrote:
>
> 
>
> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
> propose the following.
>
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
> immediate 5.1-alpha1 release.
>
> I see this as a win-win scenario for us, considering our current situation.  
> (Though it is unfortunate that Accord is included in this scenario because we 
> agreed it to be based upon TCM.)
>
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
> features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly for 
> broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
> engineers time and patience reviewing and testing.  TCM will be the biggest 
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just 
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 4.x 
> versions, just as if it had landed in 5.0.
>
>
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
> at some point decide to undo this work, while we can throw away the 
> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
> in trunk.  This is a _very_ edge case, as confidence levels on the design and 
> implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat 
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
> not our normal practice, but this work will have already received its two +1s 
> from committers, and such ongoing review effort is akin to GA stabilisation 
> work on release branches.
>
>
> I see no other ok solution in front of us that gets us at least both the 5.0 
> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
> to start experimenting with these features, and our Cassandra Summit in 
> December.
>
>
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>
>

Re: CASSANDRA-18775 (Cassandra supported OSs)

[Brandon Williams]

As noted on CASSANDRA-16565 we don't actually need sigar for anything,
so I don't see a reason to keep any of it, especially if that is going
to force us to specify OSes.

Kind Regards,
Brandon

On Fri, Oct 20, 2023 at 9:04 AM Claude Warren, Jr via dev
 wrote:
>
> I am looking at https://issues.apache.org/jira/browse/CASSANDRA-18775 and 
> want to ensure that I do not remove too many libraries.
>
> I think that preserving any sigar library where the file name contains the 
> word "linux" or "macosx" should be acceptable.  This will preserve:
> libsigar-amd64-linux.so
> libsigar-ia64-linux.so
> libsigar-ppc-linux.so
> libsigar-ppc64-aix-5.so
> libsigar-ppc64-linux.so
> libsigar-ppc64le-linux.so
> libsigar-s390x-linux.so
> libsigar-universal-macosx.dylib
> libsigar-universal64-macosx.dylib
> libsigar-x86-linux.so
>
> and remove:
>
> libsigar-amd64-freebsd-6.so
> libsigar-amd64-solaris.so
> libsigar-ia64-hpux-11.sl
> libsigar-pa-hpux-11.sl
> libsigar-ppc-aix-5.so
> libsigar-sparc-solaris.so
> libsigar-sparc64-solaris.so
> libsigar-x86-freebsd-5.so
> libsigar-x86-freebsd-6.so
> libsigar-x86-solaris.so
>
> resulting in a savings of 3,105,384 bytes out of 6,450,526 from the 
> /lib/sigar-bin directory, a 48% reduction.
>
> Does anyone see any reason _not_ to do this?

Re: Need Confluent "Create" permission for filing a CEP

[Brandon Williams]

I've added you, you should have access now.

Kind Regards,
Brandon

On Tue, Oct 10, 2023 at 1:24 AM Jaydeep Chovatia
 wrote:
>
> Hi,
>
> I want to create a new CEP request but do not see the "Create" page 
> permission on Confluent. Could someone permit me?
> Here is the CEP draft: [DRAFT] CEP - Apache Cassandra Official Repair 
> Solution - Google Docs
>
> My confluent user-id is: chovatia.jayd...@gmail.com
>
> Jaydeep

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

[Brandon Williams]

On Fri, Oct 6, 2023 at 5:50 PM David Capwell  wrote:
> Lets say you now need to host replace node1

Won't the replacement have a newer generation?

> avoid peers mutating endpoint states they don’t own

This sounds reasonable to me.

> This would be a protocol change, so would need to make sure everyone is cool 
> with me doing this in 5.0.>

I don't think it is, this is just fixing a gossip bug, and we should
do so in all affected versions.

Kind Regards,
Brandon

Re: [VOTE] Accept java-driver

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Oct 2, 2023 at 11:53 PM Mick Semb Wever  wrote:
>
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF.  This does not require acknowledgement 
> before the vote.
>
> Once the vote passes, and the SGA has been filed by the ASF Secretary, we 
> will request ASF Infra to move the datastax/java-driver as-is to 
> apache/java-driver
>
> This means all branches and tags, with all their history, will be kept.  A 
> cleaning effort has already cleaned up anything deemed not needed.
>
> Background for the donation is found in CEP-8: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>
> PMC members, please take note of (and check) the IP Clearance requirements 
> when voting.
>
> The vote will be open for 72 hours (or longer). Votes by PMC members are 
> considered binding. A vote passes if there are at least three binding +1s and 
> no -1's.
>
> regards,
> Mick

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

[Brandon Williams]

I think it could be argued that not retrying messages is a bug, I am
+1 on including this in 5.0.

Kind Regards,
Brandon

On Tue, Sep 19, 2023 at 1:16 PM David Capwell  wrote:
>
> To try to get repair more stable, I added optional retry logic (patch is 
> still in review) to a handful of critical repair verbs.  This patch is 
> disabled by default but allows you to opt-in to retries so ephemeral issues 
> don’t cause a repair to fail after running for a long time (assuming they 
> resolve within the retry window). There are 2 protocol level changes to 
> enable this: VALIDATION_RSP and SYNC_RSP now send an ACK (if the sender 
> doesn’t attach a callback, these ACKs get ignored in all versions; see 
> org.apache.cassandra.net.ResponseVerbHandler#doVerb and Verb.REPAIR_RSP).  
> Given that we have already forked, I believe we would need to give a waiver 
> to allow this patch due to this change.
>
> The patch was written on trunk, but figured back porting 5.0 would be rather 
> trivial and this was brought up during the review, so floating this to a 
> wider audience.
>
> If you look at the patch you will see that it is very large, but this is only 
> to make testing of repair coordination easier and deterministic, the biggest 
> code changes are:
>
> 1) Moving from ActiveRepairService.instance to ActiveRepairService.instance() 
> (this is the main reason so many files were touched; this was needed so unit 
> tests don’t load the whole world)
> 2) Repair no longer reaches into global space and instead is provided the 
> subsystems needed to perform repair; this change is local to repair code
>
> Both of these changes were only for testing as they allow us to simulate 1k 
> repairs in around 15 seconds with 100% deterministic execution.

Re: [DISCUSS] Addition of smile-nlp test dependency for CEP-30

[Brandon Williams]

On Wed, Sep 13, 2023 at 11:37 AM Jeff Jirsa  wrote:

> You can open a legal JIRA to confirm, but based on my understanding (and
> re-confirming reading
> https://www.apache.org/legal/resolved.html#category-a ):
>
>
We should probably get clarification here regardless, iirc this came up
when we were considering SpotBugs too.

Re: [DISCUSS] Addition of smile-nlp test dependency for CEP-30

[Brandon Williams]

I don't see any problem with this, +1.

Kind Regards,
Brandon


On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson  wrote:

> CEP-30: [Approximate Nearest Neighbor(ANN) Vector Search via
> Storage-Attached Indexes] uses the smile-nlp library
> (com.github.haifengl.smile-nlp) in its testing to allow the creation of
> word2vec embeddings for valid input into the HNSW graph index.
>
> The reason for this library is that we found that using random vectors in
> testing produced very inconsistent results. Using the smile-nlp word2vec
> implementation with the glove.3k.50d library produces repeatable results.
>
> Does anyone have any objections to the use of this library as a test only
> dependency?
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>