[ 
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733888#comment-17733888
 ] 

Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/18/23 9:45 AM:
------------------------------------------------------------------------

I am sorry it took so long to complete. The existing dtests in Python are 
rather brittle and I was balancing between the introduction of this new feature 
and not rewriting existing tests. 

Actually, I fixed one test in dtest as it was written incorrectly. Comments are 
on the PR.

I was also testing locally that proposed changes in dtests are playing nicely 
with branches 3.11 -> 4.1 (this just go just to trunk).

pr [https://github.com/apache/cassandra/pull/2390]
dtest pr [https://github.com/apache/cassandra-dtest/pull/221]
j11 pre-commit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2466/workflows/0e38394c-111e-4edc-8ee9-d21536326651]
j8 pre-commit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2466/workflows/f308aebe-3ee5-449c-95dd-05c1c4982d33]

[~brandon.williams] would you formally review it, please?


was (Author: smiklosovic):
I am sorry it took so long to complete. The existing dtests in Python are 
rather brittle and I was balancing between the introduction of this new feature 
and not rewriting existing tests. 

Actually, I fixed one test in dtest as it was written incorrectly. Comments are 
on the PR.

I was also testing locally that proposed changes in dtests are playing nicely 
with branches 3.11 -> 4.1 (this just go just to trunk).

pr [https://github.com/apache/cassandra/pull/2390]
dtest pr [https://github.com/apache/cassandra-dtest/pull/221]
j11 pre-commit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2466/workflows/0e38394c-111e-4edc-8ee9-d21536326651]
j8 pre-commit 
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2466/workflows/f308aebe-3ee5-449c-95dd-05c1c4982d33]

> 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
>             Fix For: 5.x
>
>          Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to