This is an incredible contribution. Thanks a lot!

Now, let me throw some thoughts :-)

Rolling restarts is a great example of a broader feature that could be seen as 
bulk operations on a cluster via Sidecar.

What do you think about broadening the scope of the CEP to propose a way (API) 
to perform bulk operations, and propose the current Rolling restarts as the 
first implementation for that bulk operations API? I’m proposing this as I see 
value to reuse this proposal for other bulk operations such as enabling CDC (it 
requires enabling cdc on cassandra.yml and some other operations) for better 
supporting CEP-44.

I’m not quite sold on using a PATCH to move from pending state to running 
state. Quick question, what is the goal of the pending state? I see a PATCH 
operation as modifying part of an object data. In this case, modifying the 
state looks like a change on the operation state, not on its metadata. I’d love 
to hear your thoughts on this one.

Again, thanks a lot for the contribution!
Bernardo


> On Aug 30, 2025, at 7:02 AM, Francisco Guerrero <[email protected]> wrote:
> 
> Thanks Andrés for the CEP. This is a great contribution to the project and
> aligns with the original intent of the Sidecar stated in CEP-1. I've gone
> over the CEP details and it is consistent with the internals of Sidecar.
> 
> The only suggestion I have is to keep in mind the pluggability aspect of
> Sidecar. For example, for the Distributed Restart portion of the work, we
> should consider making interfaces that would allow us to potentially move
> the responsibility of keeping the state outside of Cassandra.
> 
> Best,
> - Francisco
> 
> On 2025/08/29 19:56:08 Andrés Beck-Ruiz wrote:
>> Hello everyone,
>> 
>> We would like to propose CEP 53: Cassandra Rolling Restarts via Sidecar (
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-53%3A+Cassandra+Rolling+Restarts+via+Sidecar
>> )
>> 
>> This CEP builds off of CEP-1
>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-1%3A+Apache+Cassandra+Management+Process%28es%29+-+Deprecated>
>> and proposes a design for safe, efficient, and operator friendly rolling
>> restarts on Cassandra clusters, as well as an extensible approach for
>> persisting future cluster-wide operations in Cassandra Sidecar. We hope to
>> leverage this infrastructure in the future to implement upgrade automation.
>> 
>> We welcome all feedback and discussion. Thank you in advance for your time
>> and consideration of this proposal!
>> 
>> Best,
>> Andrés and Paulo
>> 

Reply via email to