[
https://issues.apache.org/jira/browse/YARN-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849929#comment-13849929
]
Karthik Kambatla commented on YARN-1029:
----------------------------------------
bq. Given that the shared state is in ZK, we don't need fencing if the same ZK
client does election. The reason is that, if an RM loses its ZK lease, it will
simultaneously trigger the failover and be unable to make further changes in
ZK. This exactly the semantics that we want.
bq. The ZKStateStore implementation did implement a fence operation (YARN-1222)
but it wasn't integrated with the leader election (AFAIU) even in the current
set of patches.
That is correct. The current patches don't reuse the same session for leader
election and store operations, and would be nice to add this.
That said, IIUC (please correct me otherwise), this is required only if we
don't have any fencing method. Currently, the ZK store already supports fencing
by allowing only a single RM modify the store. Given that the store supports
fencing, it should be okay for the leader election to use a separate session
(or even a separate quorum) - this interaction is similar to the ZKFC case.
If it is not a correctness issue, I would like to integrate the leader election
and store operations in a separate JIRA.
> Allow embedding leader election into the RM
> -------------------------------------------
>
> Key: YARN-1029
> URL: https://issues.apache.org/jira/browse/YARN-1029
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Karthik Kambatla
> Attachments: embedded-zkfc-approach.patch, yarn-1029-0.patch,
> yarn-1029-0.patch, yarn-1029-approach.patch
>
>
> It should be possible to embed common ActiveStandyElector into the RM such
> that ZooKeeper based leader election and notification is in-built. In
> conjunction with a ZK state store, this configuration will be a simple
> deployment option.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
