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