[
https://issues.apache.org/jira/browse/CASSANDRA-21591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111548#comment-18111548
]
Sam Tunnicliffe commented on CASSANDRA-21591:
---------------------------------------------
A Move doesn't adversely affect an inflight CMS reconfiguration, although if
the node moves far enough operators may want to run another reconfig
afterwards.
Regarding replacement, in order to be replaced a node must already be DOWN
which means any CMS reconfiguration it is involved in is doomed to fail anyway.
If the DOWN node is in the process of leaving the CMS, the attempting to
replace it will already be blocked as it will attempt to trigger another
reconfiguration, which is not allowed.
If the DOWN node is in the process of joining the CMS, the reconfiguration will
fail for the expected reasons.
In that latter case, I think it's better to allow the replacement to go through
and then cancel/resubmit the failed CMS reconfiguration.
We could add some in-jvm dtests to document this behaviour, wdyt?
> Do not let a node be decommissioned if a CMS reconfiguration involving it is
> in progress
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21591
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21591
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
> Reporter: Nivy Kani
> Assignee: Nivy Kani
> Priority: Normal
> Fix For: 6.0.x
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, `PrepareLeave` doesn't validate that the leaving node isn't part
> of any in-progress CMS reconfiguration. This can cause the
> ADVANCE_CMS_RECONFIGURATION step to fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
