You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Andy Huang (Jira)" <ji...@apache.org> on 2026/10/19 04:27:00 UTC

[jira] [Assigned] (HDDS-17130) MiniOzoneHAClusterImpl#bootstrapSCM does not wait for the bootstrapped SCM

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

Andy Huang reassigned HDDS-17130:
---------------------------------

    Assignee: Andy Huang

> MiniOzoneHAClusterImpl#bootstrapSCM does not wait for the bootstrapped SCM
> --------------------------------------------------------------------------
>
>                 Key: HDDS-17130
>                 URL: https://issues.apache.org/jira/browse/HDDS-17130
>             Project: Apache Ozone
>          Issue Type: Sub-task
>          Components: test
>            Reporter: Siyao Meng
>            Assignee: Andy Huang
>            Priority: Major
>
> In {{MiniOzoneHAClusterImpl#bootstrapSCM}} the calls to {{waitForBootstrappedNodeToBeReady}} and {{waitForConfigUpdateOnActiveSCMs}} are inside the retry loop, after the {{break}} on success. They only run on the BindException retry path, where {{scm}} may still be null, and never after a successful bootstrap. Compare {{bootstrapOzoneManager}}, which waits after the loop.
> Also, {{waitForConfigUpdateOnActiveSCMs}} checks {{scm.doesPeerExist(scm.getScmId())}}, i.e. whether each SCM has itself as a peer, instead of whether it has the new SCM.
> Tests using it (e.g. TestDatanodeSCMNodesReconfiguration) therefore do not wait for the new SCM to catch up, which is a flakiness risk.
> *Fix:* move both waits after the loop, and check {{scm.doesPeerExist(newSCMNode.getScmId())}}.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org