[
https://issues.apache.org/jira/browse/HDDS-16284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aryan Gupta updated HDDS-16284:
-------------------------------
Description:
{{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.
was:
{{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.
> 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]
