Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[PJ Fanning]

The IPMC vote only requires lazy consensus on IP Clearance matters. Detailed in:
https://incubator.apache.org/ip-clearance/

On Sun, 9 Mar 2025 at 13:18, Mick Semb Wever  wrote:
>
> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>
> All consent from original authors of the donation, and tracking of
> collected CLAs, is found in:
>  - https://github.com/riptano/ccm/issues/773
>  - 
> https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>
> These do not require acknowledgement before the vote.
>
> The code is prepared for donation at https://github.com/riptano/ccm
> (Only `master` and `cassandra-test` refs will be brought over.)
>
> Once this vote passes we will request ASF Infra to move the
> riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
> cassandra-test tag, with all its history, will be kept.  Because
> consent and CLAs were not received from all original authors the
> NOTICE file keeps additional reference to these earlier copyright
> authors.
>
> 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
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Mick Semb Wever]

The IPMC vote only requires lazy consensus on IP Clearance matters.
> Detailed in:
> https://incubator.apache.org/ip-clearance/



That's correct, the vote is directed to the Cassandra PMC.  The IPMC is
only cc'd for notification, as is required.

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Jeremiah Jordan]

+1

On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams  wrote:

> +1
>
> Kind Regards,
> Brandon
>
> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever  wrote:
> >
> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> > and its IP Clearance:
> > https://incubator.apache.org/ip-clearance/cassandra-ccm.html
> >
> > All consent from original authors of the donation, and tracking of
> > collected CLAs, is found in:
> >  - https://github.com/riptano/ccm/issues/773
> >  -
> https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
> >
> > These do not require acknowledgement before the vote.
> >
> > The code is prepared for donation at https://github.com/riptano/ccm
> > (Only `master` and `cassandra-test` refs will be brought over.)
> >
> > Once this vote passes we will request ASF Infra to move the
> > riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
> > cassandra-test tag, with all its history, will be kept.  Because
> > consent and CLAs were not received from all original authors the
> > NOTICE file keeps additional reference to these earlier copyright
> > authors.
> >
> > 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: [UPDATE] CEP-37

[Dave Herrington]

Jaydeep,

Thank you for taking time to answer my questions and for the links to the
design and overview docs, which are excellent and answer all of my
remaining questions.  Sorry I missed those links in the CEP page.

Great work and I will continue to follow your progress on this powerful new
feature.

Thanks!
-Dave

On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia 
wrote:

> Hi David,
>
> Thanks for the kind words!
>
> >Is there a goal in this CEP to make automated repair work during rolling
> upgrades, when multiple versions exist in the cluster?
> We debated a lot on this over ASF Slack
> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we want
> to have a repair function during the mixed version, but the reality is that
> currently, there is no test suite available inside Apache Cassandra to
> verify the streaming behavior during the mixed version, so the confidence
> is low.
> We agreed on the following: 1) Keeping safety in mind, we should by
> default disable the repair during mixed version 2) Add a comprehensive test
> suite 3) Allow repair during mixed version. Currently, we are at #1
>
> >Would automated repair be smart enough to automatically stop, if it sees
> incompatible versions?
> That's the plan, and we already have PR (CASSANDRA-20048
> ) out from Chris
> Lohfink. The thing we are debating is whether to stop only during major
> version mismatch or also during the minor version, and we are leaning
> towards only disabling for the major version mismatch. Regardless, this
> should be available soon.
> We are also extending this further as per feedback from David Capwell that
> we should automatically stop repair if we detect a new DC or keyspace RF is
> changed. That will be covered later as part of CASSANDRA-20414
> 
>
> >If automated repair must be disabled for the entire cluster, will this be
> a single nodetool command, or must automated repair be disabled on each
> node individually?
> Yes, it is a nodetool command and does not require any restarts! All the
> *nodetool* command details are currently covered in the design doc
> ,
> and the same details will also be available in the Cassandra overview.adoc
> 
> .
>
> >Would it make sense for automated repair to upgrade sstables, if it finds
> old formats? (Maybe this could be a feature that could be optionally
> enabled?)
> My opinion is that it should not be part of the repair. It is best suited
> as part of the Cassandra upgrade framework; I guess Paulo M is looking at
> it.
>
> >W.R.T. the repair logging tables in the system_distributed keyspace, will
> these tables have a configurable TTL, or must they be periodically
> truncated to limit their size?
> The number of entries will equal the number of Cassandra nodes in a
> cluster. There is no TTL because each row represents the repair status of
> that particular node. The entries would be automatically added/removed as
> nodes are added/removed from the Cassandra cluster.
>
> Jaydeep
>
> On Sat, Mar 8, 2025 at 7:46 AM Dave Herrington 
> wrote:
>
>> Jaydeep,
>>
>> Thank you for your excellent efforts on this mission-critical feature.
>> The stated goals of CEP-37 are noble and stand to make valuable
>> improvements for cluster operations.  I look forward to testing these new
>> capabilities.
>>
>> My apologies up-front if you’ve already answered these questions.  I did
>> read the CEP a number of times and the linked JIRAs, but these are my
>> questions that I couldn’t answer myself.
>>
>> I’m interested to understand the goals of CEP-37 W.R.T. to rolling
>> upgrades of large clusters, as I am responsible for maintaining the cluster
>> operations runbooks for a number of customers.
>>
>> Operators have to navigate the upgrade gauntlet with automated repairs
>> disabled and get all nodes upgraded within gc_grace_seconds and then do a
>> full repair, before restarting automated repairs.
>>
>> I see that CASSANDRA-7530
>> https://issues.apache.org/jira/browse/CASSANDRA-7530 is related to this.
>>
>> Is there a goal in this CEP to make automated repair work during rolling
>> upgrades, when multiple versions exist in the cluster?
>>
>> (I think this would imply that stopping automated repairs would no longer
>> be a pre-upgrade step.)
>>
>> Would automated repair be smart enough to automatically stop, if it sees
>> incompatible versions?
>>
>> Would automated repair continue between nodes with compatible versions,
>> or would it stop for the entire cluster?
>>
>> If automated repair must be disabled for the entire cluster, will this be
>> a single nodetool command, or must automated repair be disabled on each
>>

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Maxim Muzafarov]

+1 (nb)

On Sun, 9 Mar 2025 at 18:13, Jon Haddad  wrote:
>
> +1
>
>
> On Sun, Mar 9, 2025 at 9:52 AM  wrote:
>>
>> +1
>>
>>
>> On Mar 9, 2025, at 7:50 AM, Jeremiah Jordan  
>> wrote:
>>
>> +1
>>
>> On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams  wrote:
>>>
>>> +1
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever  wrote:
>>> >
>>> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>>> > and its IP Clearance:
>>> > https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>>> >
>>> > All consent from original authors of the donation, and tracking of
>>> > collected CLAs, is found in:
>>> >  - https://github.com/riptano/ccm/issues/773
>>> >  - 
>>> > https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>>> >
>>> > These do not require acknowledgement before the vote.
>>> >
>>> > The code is prepared for donation at https://github.com/riptano/ccm
>>> > (Only `master` and `cassandra-test` refs will be brought over.)
>>> >
>>> > Once this vote passes we will request ASF Infra to move the
>>> > riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
>>> > cassandra-test tag, with all its history, will be kept.  Because
>>> > consent and CLAs were not received from all original authors the
>>> > NOTICE file keeps additional reference to these earlier copyright
>>> > authors.
>>> >
>>> > 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: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[scott]

+1

> On Mar 9, 2025, at 7:50 AM, Jeremiah Jordan  wrote:
> 
> +1
> 
> On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams  > wrote:
>> +1
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever > > wrote:
>> >
>> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>> > and its IP Clearance:
>> > https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>> >
>> > All consent from original authors of the donation, and tracking of
>> > collected CLAs, is found in:
>> >  - https://github.com/riptano/ccm/issues/773
>> >  - 
>> > https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>> >
>> > These do not require acknowledgement before the vote.
>> >
>> > The code is prepared for donation at https://github.com/riptano/ccm
>> > (Only `master` and `cassandra-test` refs will be brought over.)
>> >
>> > Once this vote passes we will request ASF Infra to move the
>> > riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
>> > cassandra-test tag, with all its history, will be kept.  Because
>> > consent and CLAs were not received from all original authors the
>> > NOTICE file keeps additional reference to these earlier copyright
>> > authors.
>> >
>> > 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: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Jon Haddad]

+1


On Sun, Mar 9, 2025 at 9:52 AM  wrote:

> +1
>
>
> On Mar 9, 2025, at 7:50 AM, Jeremiah Jordan 
> wrote:
>
> +1
>
> On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams  wrote:
>
>> +1
>>
>> Kind Regards,
>> Brandon
>>
>> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever  wrote:
>> >
>> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>> > and its IP Clearance:
>> > https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>> >
>> > All consent from original authors of the donation, and tracking of
>> > collected CLAs, is found in:
>> >  - https://github.com/riptano/ccm/issues/773
>> >  -
>> https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>> >
>> > These do not require acknowledgement before the vote.
>> >
>> > The code is prepared for donation at https://github.com/riptano/ccm
>> > (Only `master` and `cassandra-test` refs will be brought over.)
>> >
>> > Once this vote passes we will request ASF Infra to move the
>> > riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
>> > cassandra-test tag, with all its history, will be kept.  Because
>> > consent and CLAs were not received from all original authors the
>> > NOTICE file keeps additional reference to these earlier copyright
>> > authors.
>> >
>> > 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
>>
>
>

[VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Mick Semb Wever]

Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
and its IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-ccm.html

All consent from original authors of the donation, and tracking of
collected CLAs, is found in:
 - https://github.com/riptano/ccm/issues/773
 - 
https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8

These do not require acknowledgement before the vote.

The code is prepared for donation at https://github.com/riptano/ccm
(Only `master` and `cassandra-test` refs will be brought over.)

Once this vote passes we will request ASF Infra to move the
riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
cassandra-test tag, with all its history, will be kept.  Because
consent and CLAs were not received from all original authors the
NOTICE file keeps additional reference to these earlier copyright
authors.

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: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Mick Semb Wever]

   .



> 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.



+1

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever  wrote:
>
> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
>
> All consent from original authors of the donation, and tracking of
> collected CLAs, is found in:
>  - https://github.com/riptano/ccm/issues/773
>  - 
> https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
>
> These do not require acknowledgement before the vote.
>
> The code is prepared for donation at https://github.com/riptano/ccm
> (Only `master` and `cassandra-test` refs will be brought over.)
>
> Once this vote passes we will request ASF Infra to move the
> riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
> cassandra-test tag, with all its history, will be kept.  Because
> consent and CLAs were not received from all original authors the
> NOTICE file keeps additional reference to these earlier copyright
> authors.
>
> 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: [UPDATE] CEP-37

[Jon Haddad]

This is all really exciting.  Getting a built in, orchestrated repair is a
massive achievement.  Thank you for your work on this, it's incredibly
valuable to the community!!

Jon

On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia 
wrote:

> No problem, Dave! Thank you.
>
> Jaydeep
>
> On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
> wrote:
>
>> Jaydeep,
>>
>> Thank you for taking time to answer my questions and for the links to the
>> design and overview docs, which are excellent and answer all of my
>> remaining questions.  Sorry I missed those links in the CEP page.
>>
>> Great work and I will continue to follow your progress on this powerful
>> new feature.
>>
>> Thanks!
>> -Dave
>>
>> On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for the kind words!
>>>
>>> >Is there a goal in this CEP to make automated repair work during
>>> rolling upgrades, when multiple versions exist in the cluster?
>>> We debated a lot on this over ASF Slack
>>> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we want
>>> to have a repair function during the mixed version, but the reality is that
>>> currently, there is no test suite available inside Apache Cassandra to
>>> verify the streaming behavior during the mixed version, so the confidence
>>> is low.
>>> We agreed on the following: 1) Keeping safety in mind, we should by
>>> default disable the repair during mixed version 2) Add a comprehensive test
>>> suite 3) Allow repair during mixed version. Currently, we are at #1
>>>
>>> >Would automated repair be smart enough to automatically stop, if it
>>> sees incompatible versions?
>>> That's the plan, and we already have PR (CASSANDRA-20048
>>> ) out from Chris
>>> Lohfink. The thing we are debating is whether to stop only during major
>>> version mismatch or also during the minor version, and we are leaning
>>> towards only disabling for the major version mismatch. Regardless, this
>>> should be available soon.
>>> We are also extending this further as per feedback from David
>>> Capwell that we should automatically stop repair if we detect a new DC or
>>> keyspace RF is changed. That will be covered later as part of
>>> CASSANDRA-20414 
>>>
>>> >If automated repair must be disabled for the entire cluster, will this
>>> be a single nodetool command, or must automated repair be disabled on each
>>> node individually?
>>> Yes, it is a nodetool command and does not require any restarts! All the
>>> *nodetool* command details are currently covered in the design doc
>>> ,
>>> and the same details will also be available in the Cassandra
>>> overview.adoc
>>> 
>>> .
>>>
>>> >Would it make sense for automated repair to upgrade sstables, if it
>>> finds old formats? (Maybe this could be a feature that could be optionally
>>> enabled?)
>>> My opinion is that it should not be part of the repair. It is best
>>> suited as part of the Cassandra upgrade framework; I guess Paulo M is
>>> looking at it.
>>>
>>> >W.R.T. the repair logging tables in the system_distributed keyspace,
>>> will these tables have a configurable TTL, or must they be periodically
>>> truncated to limit their size?
>>> The number of entries will equal the number of Cassandra nodes in a
>>> cluster. There is no TTL because each row represents the repair status of
>>> that particular node. The entries would be automatically added/removed as
>>> nodes are added/removed from the Cassandra cluster.
>>>
>>> Jaydeep
>>>
>>> On Sat, Mar 8, 2025 at 7:46 AM Dave Herrington 
>>> wrote:
>>>
 Jaydeep,

 Thank you for your excellent efforts on this mission-critical feature.
 The stated goals of CEP-37 are noble and stand to make valuable
 improvements for cluster operations.  I look forward to testing these new
 capabilities.

 My apologies up-front if you’ve already answered these questions.  I
 did read the CEP a number of times and the linked JIRAs, but these are my
 questions that I couldn’t answer myself.

 I’m interested to understand the goals of CEP-37 W.R.T. to rolling
 upgrades of large clusters, as I am responsible for maintaining the cluster
 operations runbooks for a number of customers.

 Operators have to navigate the upgrade gauntlet with automated repairs
 disabled and get all nodes upgraded within gc_grace_seconds and then do a
 full repair, before restarting automated repairs.

 I see that CASSANDRA-7530
 https://issues.apache.org/jira/browse/CASSANDRA-7530 is related to
 this.

 Is there a goal in this CEP to make 

Re: [UPDATE] CEP-37

[Jaydeep Chovatia]

No problem, Dave! Thank you.

Jaydeep

On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
wrote:

> Jaydeep,
>
> Thank you for taking time to answer my questions and for the links to the
> design and overview docs, which are excellent and answer all of my
> remaining questions.  Sorry I missed those links in the CEP page.
>
> Great work and I will continue to follow your progress on this powerful
> new feature.
>
> Thanks!
> -Dave
>
> On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Hi David,
>>
>> Thanks for the kind words!
>>
>> >Is there a goal in this CEP to make automated repair work during rolling
>> upgrades, when multiple versions exist in the cluster?
>> We debated a lot on this over ASF Slack
>> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we want
>> to have a repair function during the mixed version, but the reality is that
>> currently, there is no test suite available inside Apache Cassandra to
>> verify the streaming behavior during the mixed version, so the confidence
>> is low.
>> We agreed on the following: 1) Keeping safety in mind, we should by
>> default disable the repair during mixed version 2) Add a comprehensive test
>> suite 3) Allow repair during mixed version. Currently, we are at #1
>>
>> >Would automated repair be smart enough to automatically stop, if it sees
>> incompatible versions?
>> That's the plan, and we already have PR (CASSANDRA-20048
>> ) out from Chris
>> Lohfink. The thing we are debating is whether to stop only during major
>> version mismatch or also during the minor version, and we are leaning
>> towards only disabling for the major version mismatch. Regardless, this
>> should be available soon.
>> We are also extending this further as per feedback from David
>> Capwell that we should automatically stop repair if we detect a new DC or
>> keyspace RF is changed. That will be covered later as part of
>> CASSANDRA-20414 
>>
>> >If automated repair must be disabled for the entire cluster, will this
>> be a single nodetool command, or must automated repair be disabled on each
>> node individually?
>> Yes, it is a nodetool command and does not require any restarts! All the
>> *nodetool* command details are currently covered in the design doc
>> ,
>> and the same details will also be available in the Cassandra
>> overview.adoc
>> 
>> .
>>
>> >Would it make sense for automated repair to upgrade sstables, if it
>> finds old formats? (Maybe this could be a feature that could be optionally
>> enabled?)
>> My opinion is that it should not be part of the repair. It is best suited
>> as part of the Cassandra upgrade framework; I guess Paulo M is looking at
>> it.
>>
>> >W.R.T. the repair logging tables in the system_distributed keyspace,
>> will these tables have a configurable TTL, or must they be periodically
>> truncated to limit their size?
>> The number of entries will equal the number of Cassandra nodes in a
>> cluster. There is no TTL because each row represents the repair status of
>> that particular node. The entries would be automatically added/removed as
>> nodes are added/removed from the Cassandra cluster.
>>
>> Jaydeep
>>
>> On Sat, Mar 8, 2025 at 7:46 AM Dave Herrington 
>> wrote:
>>
>>> Jaydeep,
>>>
>>> Thank you for your excellent efforts on this mission-critical feature.
>>> The stated goals of CEP-37 are noble and stand to make valuable
>>> improvements for cluster operations.  I look forward to testing these new
>>> capabilities.
>>>
>>> My apologies up-front if you’ve already answered these questions.  I did
>>> read the CEP a number of times and the linked JIRAs, but these are my
>>> questions that I couldn’t answer myself.
>>>
>>> I’m interested to understand the goals of CEP-37 W.R.T. to rolling
>>> upgrades of large clusters, as I am responsible for maintaining the cluster
>>> operations runbooks for a number of customers.
>>>
>>> Operators have to navigate the upgrade gauntlet with automated repairs
>>> disabled and get all nodes upgraded within gc_grace_seconds and then do a
>>> full repair, before restarting automated repairs.
>>>
>>> I see that CASSANDRA-7530
>>> https://issues.apache.org/jira/browse/CASSANDRA-7530 is related to this.
>>>
>>> Is there a goal in this CEP to make automated repair work during rolling
>>> upgrades, when multiple versions exist in the cluster?
>>>
>>> (I think this would imply that stopping automated repairs would no
>>> longer be a pre-upgrade step.)
>>>
>>> Would automated repair be smart enough to automatically stop, if it sees
>>> incompatible versions?
>>>
>>> Would automated repair contin

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

[Blake Eggleston]

+1

On Sun, Mar 9, 2025, at 5:17 AM, Mick Semb Wever wrote:
> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-ccm.html
> 
> All consent from original authors of the donation, and tracking of
> collected CLAs, is found in:
> - https://github.com/riptano/ccm/issues/773
> - 
> https://docs.google.com/spreadsheets/d/1lXDK3c7_-TZh845knVZ8zvJf65x2o03ACqY3pfdXZR8
> 
> These do not require acknowledgement before the vote.
> 
> The code is prepared for donation at https://github.com/riptano/ccm
> (Only `master` and `cassandra-test` refs will be brought over.)
> 
> Once this vote passes we will request ASF Infra to move the
> riptano/ccm as-is to apache/cassandra-ccm  . The master branch and the
> cassandra-test tag, with all its history, will be kept.  Because
> consent and CLAs were not received from all original authors the
> NOTICE file keeps additional reference to these earlier copyright
> authors.
> 
> 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: [UPDATE] CEP-37

[Jaydeep Chovatia]

Thanks a lot, Jon!
This has truly been a team effort, with Andy Tolbert, Chris Lohfink,
Francisco Guerrero, and Kristijonas Zalys all contributing over the past
year. The credit belongs to everyone!

Jaydeep





On Sun, Mar 9, 2025 at 2:35 PM Jon Haddad  wrote:

> This is all really exciting.  Getting a built in, orchestrated repair is a
> massive achievement.  Thank you for your work on this, it's incredibly
> valuable to the community!!
>
> Jon
>
> On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> No problem, Dave! Thank you.
>>
>> Jaydeep
>>
>> On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
>> wrote:
>>
>>> Jaydeep,
>>>
>>> Thank you for taking time to answer my questions and for the links to
>>> the design and overview docs, which are excellent and answer all of my
>>> remaining questions.  Sorry I missed those links in the CEP page.
>>>
>>> Great work and I will continue to follow your progress on this powerful
>>> new feature.
>>>
>>> Thanks!
>>> -Dave
>>>
>>> On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
>>>
 Hi David,

 Thanks for the kind words!

 >Is there a goal in this CEP to make automated repair work during
 rolling upgrades, when multiple versions exist in the cluster?
 We debated a lot on this over ASF Slack
 (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we want
 to have a repair function during the mixed version, but the reality is that
 currently, there is no test suite available inside Apache Cassandra to
 verify the streaming behavior during the mixed version, so the confidence
 is low.
 We agreed on the following: 1) Keeping safety in mind, we should by
 default disable the repair during mixed version 2) Add a comprehensive test
 suite 3) Allow repair during mixed version. Currently, we are at #1

 >Would automated repair be smart enough to automatically stop, if it
 sees incompatible versions?
 That's the plan, and we already have PR (CASSANDRA-20048
 ) out from
 Chris Lohfink. The thing we are debating is whether to stop only during
 major version mismatch or also during the minor version, and we are leaning
 towards only disabling for the major version mismatch. Regardless, this
 should be available soon.
 We are also extending this further as per feedback from David
 Capwell that we should automatically stop repair if we detect a new DC or
 keyspace RF is changed. That will be covered later as part of
 CASSANDRA-20414 

 >If automated repair must be disabled for the entire cluster, will this
 be a single nodetool command, or must automated repair be disabled on each
 node individually?
 Yes, it is a nodetool command and does not require any restarts! All
 the *nodetool* command details are currently covered in the design doc
 ,
 and the same details will also be available in the Cassandra
 overview.adoc
 
 .

 >Would it make sense for automated repair to upgrade sstables, if it
 finds old formats? (Maybe this could be a feature that could be optionally
 enabled?)
 My opinion is that it should not be part of the repair. It is best
 suited as part of the Cassandra upgrade framework; I guess Paulo M is
 looking at it.

 >W.R.T. the repair logging tables in the system_distributed keyspace,
 will these tables have a configurable TTL, or must they be periodically
 truncated to limit their size?
 The number of entries will equal the number of Cassandra nodes in a
 cluster. There is no TTL because each row represents the repair status of
 that particular node. The entries would be automatically added/removed as
 nodes are added/removed from the Cassandra cluster.

 Jaydeep

 On Sat, Mar 8, 2025 at 7:46 AM Dave Herrington 
 wrote:

> Jaydeep,
>
> Thank you for your excellent efforts on this mission-critical
> feature.  The stated goals of CEP-37 are noble and stand to make valuable
> improvements for cluster operations.  I look forward to testing these new
> capabilities.
>
> My apologies up-front if you’ve already answered these questions.  I
> did read the CEP a number of times and the linked JIRAs, but these are my
> questions that I couldn’t answer myself.
>
> I’m interested to understand the goals of CEP-37 W.R.T. to rolling
> upgrades of large clusters, as I am responsible for maintaining the 
> cluster
> operations runb