[ 
https://issues.apache.org/jira/browse/HDDS-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mohammadhani Fouladgar updated HDDS-16303:
------------------------------------------
    Description: 
When SCM leadership moves to a newly added SCM that a client (the OM) does not 
yet have in its configuration, the client cannot reach the leader and the 
operation fails.

 

*Root cause:* 
{{SCMBlockLocationFailoverProxyProvider.performFailoverToAssignedLeader()}} 
matches {{ServerNotLeaderException.getSuggestedLeader()}} against 
{{scmProxyInfoMap}}; a non-configured leader yields {{updatedLeaderNodeID = 
null}} and it round-robins the old followers. The container-location proxy 
provider behaves the same way.

*Result:* transferring SCM leadership to a not-yet-known SCM strands every 
config-stale SCM client even though the SCM Ratis ring is healthy.

*Proposed change:*

* Allow the SCM failover proxy providers (block-location and 
container-location) to construct a proxy to the suggested-leader address 
returned in {{ServerNotLeaderException}} even when it is not in static config, 
and route to it.

* Do this safely: validate/allowlist the suggested address (require it to 
resolve within the configured service/security realm) so a peer cannot redirect 
a client to an arbitrary host. This preserves operator-controlled membership 
while removing thehard failure.

 

Acceptance criteria:

* With a new SCM as leader and clients still on the old config, client 
operations succeed by following the suggested SCM leader.

* A suggested leader outside the trusted SCM service is rejected (negative 
test).

* Applies to both the SCM block-location and container-location failover 
providers.

  was:When SCM leadership moves to a newly added SCM that a client (the OM) 
does not yet have in its configuration, the client cannot reach the leader and 
the operation fails.


> Allow SCM clients to route to a Ratis-suggested SCM leader that is not in the 
> client's static config (dynamic leader discovery)
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HDDS-16303
>                 URL: https://issues.apache.org/jira/browse/HDDS-16303
>             Project: Apache Ozone
>          Issue Type: New Feature
>            Reporter: Mohammadhani Fouladgar
>            Assignee: Mohammadhani Fouladgar
>            Priority: Major
>
> When SCM leadership moves to a newly added SCM that a client (the OM) does 
> not yet have in its configuration, the client cannot reach the leader and the 
> operation fails.
>  
> *Root cause:* 
> {{SCMBlockLocationFailoverProxyProvider.performFailoverToAssignedLeader()}} 
> matches {{ServerNotLeaderException.getSuggestedLeader()}} against 
> {{scmProxyInfoMap}}; a non-configured leader yields {{updatedLeaderNodeID = 
> null}} and it round-robins the old followers. The container-location proxy 
> provider behaves the same way.
> *Result:* transferring SCM leadership to a not-yet-known SCM strands every 
> config-stale SCM client even though the SCM Ratis ring is healthy.
> *Proposed change:*
> * Allow the SCM failover proxy providers (block-location and 
> container-location) to construct a proxy to the suggested-leader address 
> returned in {{ServerNotLeaderException}} even when it is not in static 
> config, and route to it.
> * Do this safely: validate/allowlist the suggested address (require it to 
> resolve within the configured service/security realm) so a peer cannot 
> redirect a client to an arbitrary host. This preserves operator-controlled 
> membership while removing thehard failure.
>  
> Acceptance criteria:
> * With a new SCM as leader and clients still on the old config, client 
> operations succeed by following the suggested SCM leader.
> * A suggested leader outside the trusted SCM service is rejected (negative 
> test).
> * Applies to both the SCM block-location and container-location failover 
> providers.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to