Karthik Kambatla created YARN-5709:
--------------------------------------
Summary: Cleanup Curator-based leader election code
Key: YARN-5709
URL: https://issues.apache.org/jira/browse/YARN-5709
Project: Hadoop YARN
Issue Type: Improvement
Components: resourcemanager
Affects Versions: 2.8.0
Reporter: Karthik Kambatla
Priority: Critical
While reviewing YARN-5677 and YARN-5694, I noticed we could make the
curator-based election code cleaner. It is nicer to get this fixed in 2.8
before we ship it, but this can be done at a later time as well.
# By EmbeddedElector, we meant it was running as part of the RM daemon. Since
the Curator-based elector is also running embedded, I feel the code should be
checking for {{!curatorBased}} instead of {{isEmbeddedElector}}
# {{LeaderElectorService}} should probably be named
{{CuratorBasedEmbeddedElectorService}} or some such.
# The code that initializes the elector should be at the same place
irrespective of whether it is curator-based or not.
# We seem to be caching the CuratorFramework instance in RM. It makes more
sense for it to be in RMContext. If others are okay with it, we might even be
better of having {{RMContext#getCurator()}} method to lazily create the curator
framework and then cache it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
