[
https://issues.apache.org/jira/browse/HDDS-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108604#comment-18108604
]
Ivan Andika commented on HDDS-16284:
------------------------------------
[~aryangupta1998] I saw a lot of OM and SCM leader configuration changes like
in HDDS-16303, HDDS-16302, HDDS-16301, HDDS-16300, etc.
Can you help to consolidate these tasks together and coordinate with the other
contributors for this undertaking.
Also we need to think of the design first. Please see HDDS-14769 and HDDS-14510
and HDDS-3936 for the previous issues. One notable point is that the
client-side OM / SCM node IDs might not be the same as the one in defined in
the server configuration (e.g. scm1 in client and server might be different if
not configured properly).
> 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
> Priority: Major
>
> {{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]
