[
https://issues.apache.org/jira/browse/HDDS-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787126#comment-16787126
]
Tsz Wo Nicholas Sze commented on HDDS-699:
------------------------------------------
> I think here you mean getAncestorCounts. ...
I do mean getAncestorNodeMap. It only returns one of the node of an ancestor,
which is a bug, since two excluded nodes under the same ancestor may or may not
overlap, depending on the numLevelToExclude (ancestorGen).
In the 05 patch, getAncestorNodeMap and getAncestorCountMap should be combined
to one method, as shown in [getAncestorCounts in this
comment|https://issues.apache.org/jira/browse/HDDS-699?focusedCommentId=16786248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16786248].
> would like to keep current behavior to fit its function name. Otherwise
> people may has questions.
It is common to define a node to be its own ancestor. For example, see
https://en.wikipedia.org/wiki/Lowest_common_ancestor
> Detect Ozone Network topology
> -----------------------------
>
> Key: HDDS-699
> URL: https://issues.apache.org/jira/browse/HDDS-699
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Xiaoyu Yao
> Assignee: Sammi Chen
> Priority: Major
> Attachments: HDDS-699.00.patch, HDDS-699.01.patch, HDDS-699.02.patch,
> HDDS-699.03.patch, HDDS-699.04.patch, HDDS-699.05.patch
>
>
> Traditionally this has been implemented in Hadoop via script or customizable
> java class. One thing we want to add here is the flexible multi-level support
> instead of fixed levels like DC/Rack/NG/Node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
