Aryan Gupta created HDDS-16284:
----------------------------------
Summary: Make SCM nodeId -> raftPeerId resolution dynamic on SCM
HA reconfiguration
Key: HDDS-16284
URL: https://issues.apache.org/jira/browse/HDDS-16284
Project: Apache Ozone
Issue Type: Improvement
Reporter: Aryan Gupta
Assignee: Aryan Gupta
{{ozone admin scm transfer --new-leader-id}} now accepts either SCM UUID
(raftPeerId) or SCM nodeId.
However, nodeId-based resolution relies on {{SCMHANodeDetails}} loaded at
startup.
When a new SCM is added via {{ozone scm --bootstrap}} and leader SCM is not
restarted, the new node may exist in Ratis group but not in leader’s in-memory
{{{}SCMHANodeDetails{}}}. In that case, transfer by nodeId fails, while
transfer by UUID still works.
Current Behavior
* UUID/raftPeerId path works for all members present in current Raft group.
* nodeId path works only for SCMs known in leader’s startup HA metadata/config
snapshot.
* For unknown/unresolved IDs, existing {{Target ... not found in group [...]}}
behavior is preserved.
Expected Behavior
After SCM membership changes (add/remove), leader should refresh node metadata
used for nodeId resolution, so nodeId-based transfer works for newly
bootstrapped SCMs without SCM restart (provided config metadata is available).
Proposed Approach
# Use {{SCMStateMachine.notifyConfigurationChanged(...)}} as the trigger point
for membership updates.
# Introduce/extend a mutable SCM HA peer metadata registry (local + peers)
used by transfer resolution and related components.
# On reconfiguration event, reconcile current Raft peers with SCM metadata:
** add newly discovered peers,
** remove decommissioned peers,
** refresh nodeId/address mapping from config (and/or available runtime
source).
# Keep backward-compatible fallback:
** if nodeId cannot be resolved, pass ID through so existing Ratis error
remains unchanged.
# Update dependent components that currently hold startup-only peer maps (e.g.
snapshot provider paths) to consume refreshed metadata.
Acceptance Criteria
* After {{ozone scm --bootstrap}} (without leader restart), leadership
transfer by {{--new-leader-id <nodeId>}} succeeds for the new SCM when metadata
is resolvable.
* Transfer by UUID continues to work unchanged.
* Unknown ID behavior remains unchanged ({{{}Target ... not found in group
[...]{}}}).
* Add/remove peer reconfiguration does not regress existing HA behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
