You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Maxwell Guo (Jira)" <ji...@apache.org> on 2023/06/06 05:38:00 UTC
[jira] [Comment Edited] (CASSANDRA-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729592#comment-17729592 ]
Maxwell Guo edited comment on CASSANDRA-18555 at 6/6/23 5:37 AM:
-----------------------------------------------------------------
Hi [~chovatia.jaydeep@gmail.com] I have left some comments on your pr , can you take a look at them ? And I think we need some CI .
Besides, I suggest changing the status of the output from a simple boolean value to some status value string, such as: INIT, PROCESSING, FAILED,SUCCESS.
The states that can be expressed may be a little more than simple Boolean, and it is more general.
[~Bereng]WDYT?
was (Author: maxwellguo):
Hi [~chovatia.jaydeep@gmail.com] I have left some comments on your pr , can you take a look at them ? And I think we need some CI .
Besides, I suggest changing the status of the output from a simple boolean value to some status value string, such as: INIT, PROCESSING, FAILED,SUCCESS.
The states that can be expressed may be a little more than simple Boolean, and it is more general.
> A new nodetool/JMX command that tells whether node's decommission failed or not
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
> Reporter: Jaydeepkumar Chovatia
> Assignee: Jaydeepkumar Chovatia
> Priority: Normal
>
> Currently, when a node is being decommissioned and if any failure happens, then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to hours to days. There are various scenarios in that the caller may need to probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at scale in a large-scale fleet, then this becomes a bottleneck and require constant operator intervention.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org