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.

CASSANDRA-19779 in 5.0-rc

[Štefan Miklošovič]

I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I
think it was introduced in (2) and it behaves like this (3).

Regards

(1) https://issues.apache.org/jira/browse/CASSANDRA-19779

(2)
https://issues.apache.org/jira/browse/CASSANDRA-18464?focusedCommentId=17868946&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868946

(3)
https://issues.apache.org/jira/browse/CASSANDRA-19779?focusedCommentId=17868944&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868944

Re: CASSANDRA-19779 in 5.0-rc

[Jeff Jirsa]

+1 Should block 

> On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič  wrote:
> 
> 
> I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I 
> think it was introduced in (2) and it behaves like this (3).
> 
> Regards
> 
> (1) https://issues.apache.org/jira/browse/CASSANDRA-19779
> 
> (2) 
> https://issues.apache.org/jira/browse/CASSANDRA-18464?focusedCommentId=17868946&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868946
> 
> (3) 
> https://issues.apache.org/jira/browse/CASSANDRA-19779?focusedCommentId=17868944&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868944
> 

Re: CASSANDRA-19779 in 5.0-rc

[Patrick McFadin]

This is a weird regression but I'm borderline on this being a blocker. On a
brand new node starting, this comes up but goes away on the first reboot of
the node. What I don't get is why directIO is disabled if there is no
commit log. What's specific about that?

Patrick

On Fri, Jul 26, 2024 at 7:41 AM Jeff Jirsa  wrote:

> +1 Should block
>
> On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič 
> wrote:
>
> 
> I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I
> think it was introduced in (2) and it behaves like this (3).
>
> Regards
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-19779
>
> (2)
> https://issues.apache.org/jira/browse/CASSANDRA-18464?focusedCommentId=17868946&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868946
>
> (3)
> https://issues.apache.org/jira/browse/CASSANDRA-19779?focusedCommentId=17868944&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868944
>
>

Re: Welcome Joey Lynch as Cassandra PMC member

[Maxim Muzafarov]

My congratulations Joseph Lynch!

On Thu, 25 Jul 2024 at 18:15, Paulo Motta  wrote:
>
> Congratulations Joey!
>
> On Thu, 25 Jul 2024 at 00:55 Venkata Hari Krishna Nukala 
>  wrote:
>>
>> Congratulations Joey!!
>>
>> On Thu, 25 Jul 2024 at 7:20 AM, Joseph Lynch  wrote:
>>>
>>> Thank you all for the warm wishes and I greatly appreciate this opportunity!
>>>
>>> This is such a great community and I am proud to be part of it.
>>>
>>> Cheers!
>>> -Joey
>>>
>>> On Wed, Jul 24, 2024 at 10: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

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

[Yifan Cai]

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: [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: CASSANDRA-19779 in 5.0-rc

[Josh McKenzie]

+1 to should block as well.

On Fri, Jul 26, 2024, at 12:15 PM, Patrick McFadin wrote:
> This is a weird regression but I'm borderline on this being a blocker. On a 
> brand new node starting, this comes up but goes away on the first reboot of 
> the node. What I don't get is why directIO is disabled if there is no commit 
> log. What's specific about that?
> 
> Patrick
> 
> On Fri, Jul 26, 2024 at 7:41 AM Jeff Jirsa  wrote:
>> 
>> +1 Should block 
>> 
>>> On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič  
>>> wrote:
>>> 
>>> I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I 
>>> think it was introduced in (2) and it behaves like this (3).
>>> 
>>> Regards
>>> 
>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-19779
>>> 
>>> (2) 
>>> https://issues.apache.org/jira/browse/CASSANDRA-18464?focusedCommentId=17868946&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868946
>>> 
>>> (3) 
>>> https://issues.apache.org/jira/browse/CASSANDRA-19779?focusedCommentId=17868944&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17868944
>>> 

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

[Jeff Jirsa]

Everyone has a low risk change they want to backport to every branch, 4.0 and 
4.1 in particular are way past the point we should be adding features 

The policy exists and it’s a pure feature not a regression





> On Jul 26, 2024, at 9:59 AM, Brandon Williams  wrote:
> 
> 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: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

[Yifan Cai]

Thanks Jeff for restating the policy.

According to the release lifecycle doc

>
>- Missing features from newer generation releases are back-ported on
>per - PMC vote basis.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

We do not have a policy to prevent new features strictly for the branches
in maintenance state.

IMO, the patch qualifies as the missing feature. (As said, it is useful for
Cassandra Analytics, and it is good to have the same bridge implementation
amongst different cassandra versions)

Therefore, I would like to call for a vote.

On Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa  wrote:

> Everyone has a low risk change they want to backport to every branch, 4.0
> and 4.1 in particular are way past the point we should be adding features
>
> The policy exists and it’s a pure feature not a regression
>
>
>
>
>
> > On Jul 26, 2024, at 9:59 AM, Brandon Williams  wrote:
> >
> > 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: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

[J. D. Jordan]

I thought the server now has the ability to write out old sstable versions?  So you could use the CQLSSTableWriter from 5.0/trunk to write out sstables 4.0 can read?On Jul 26, 2024, at 1:07 PM, Yifan Cai  wrote:



Caution: The sender name (Yifan Cai) is different from their email address (yc25c...@gmail.com), which may indicate an impersonation attempt. Verify the email's authenticity with the sender using your organization's trusted contact list before replying or taking further action.






Secured by Check Point






Thanks Jeff for restating the policy.According to the release lifecycle docMissing features from newer generation releases are back-ported on per - PMC vote basis.https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle We do not have a policy to prevent new features strictly for the branches in maintenance state. IMO, the patch qualifies as the missing feature. (As said, it is useful for Cassandra Analytics, and it is good to have the same bridge implementation amongst different cassandra versions)Therefore, I would like to call for a vote. On Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa  wrote:Everyone has a low risk change they want to backport to every branch, 4.0 and 4.1 in particular are way past the point we should be adding features 

The policy exists and it’s a pure feature not a regression





> On Jul 26, 2024, at 9:59 AM, Brandon Williams  wrote:
> 
> 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: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

[Yifan Cai]

Hi Jeremiah,

It is an interesting idea. As of now, I think it is too much of a risk (or
not feasible at all) to only use 5.0/trunk Cassandra-all dependency in
Cassandra Analytics, since it depends on other components in Cassandra.

- Yifan

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

[Jeff Jirsa]

On Jul 26, 2024, at 11:09 AM, Yifan Cai  wrote:Thanks Jeff for restating the policy.According to the release lifecycle docMissing features from newer generation releases are back-ported on per - PMC vote basis.https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle We do not have a policy to prevent new features strictly for the branches in maintenance state. IMO, the patch qualifies as the missing feature. (As said, it is useful for Cassandra Analytics, and it is good to have the same bridge implementation amongst different cassandra versions)Therefore, I would like to call for a vote. SureI’m -1 on 4.0 and 4.1- JeffOn Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa  wrote:Everyone has a low risk change they want to backport to every branch, 4.0 and 4.1 in particular are way past the point we should be adding features 

The policy exists and it’s a pure feature not a regression





> On Jul 26, 2024, at 9:59 AM, Brandon Williams  wrote:
> 
> 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