[
https://issues.apache.org/jira/browse/YARN-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla updated YARN-1029:
-----------------------------------
Attachment: embedded-zkfc-approach.patch
Also uploading embedded-zkfc-approach that I worked on earlier. It might not
apply to trunk/ branch-2 anymore though. The uploaded patch doesn't remove any
of the overheads or handle short-circuit.
After having implemented both approaches, I sincerely feel the
ActiveStandbyElector approach is simpler, cleaner, straight-forward than the
embedded ZKFC approach. Refactoring ZKFC will only add more work, without
apparent gains.
When working on the embedded ZKFC approach, I ran it by Todd and he suggested
we might want to use ActiveStandbyElector directly and do away with unnecessary
failover code paths if we are not using rest of the ZKFC features. Thanks to
his suggestion, the code definitely looks simpler that way.
[~vinodkv] - is there a good technical reason for using ZKFC instead of
ActiveStandbyElector directly. In this case, we only need election and will be
using ZKFC for the elector.
> 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-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)
