[
https://issues.apache.org/jira/browse/YARN-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050391#comment-15050391
]
Karthik Kambatla commented on YARN-4438:
----------------------------------------
Would very much like for us to use Curator for leader election. May be, HDFS
could also do the same in the future.
Quickly skimmed through the patch. High-level comments:
# IIRR we use the same ZK-quorum for both leader election and the store. Can we
re-use the CuratorFramework so leader-election and store-operations are fully
consistent. Otherwise, the clients (and their individual timeouts etc.) could
lead to inconsistencies?
# Would it be possible to hide the implementation of the leader-election -
ActiveStandbyElector vs CuratorElector - behind EmbeddedElector? AdminService
or RM don't need to know the details?
In any case, having written some Curator code in the past, I would like to
review the code more closely.
> Implement RM leader election with curator
> -----------------------------------------
>
> Key: YARN-4438
> URL: https://issues.apache.org/jira/browse/YARN-4438
> Project: Hadoop YARN
> Issue Type: Improvement
> Reporter: Jian He
> Assignee: Jian He
> Attachments: YARN-4438.1.patch
>
>
> This is to implement the leader election with curator instead of the
> ActiveStandbyElector from common package, this also avoids adding more
> configs in common to suit RM's own needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
