[ https://issues.apache.org/jira/browse/YARN-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jian He updated YARN-5709: -------------------------- Attachment: yarn-5709-branch-2.8.01.patch > Cleanup leader election configs and pluggability > ------------------------------------------------ > > 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 > Assignee: Karthik Kambatla > Priority: Critical > Fix For: 2.9.0, 3.0.0-alpha2 > > Attachments: yarn-5709-branch-2.8.01.patch, > yarn-5709-branch-2.8.patch, yarn-5709-wip.2.patch, yarn-5709.1.patch, > yarn-5709.2.patch, yarn-5709.3.patch, yarn-5709.4.patch > > > 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: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org