[YARN-5709] Cleanup leader election configs and pluggability

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.8.0
• Fix Version/s: 2.8.0, 3.0.0-alpha2
• Component/s: resourcemanager
• Target Version/s: 2.8.0, 3.0.0-alpha2
• Assignee: Karthik Kambatla
• Reporter: Karthik Kambatla
• Created: 04/Oct/16 19:33
• Updated: 25/Oct/19 20:27
• Resolved: 30/Dec/16 00:29

Description

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.

1. 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
2. LeaderElectorService should probably be named CuratorBasedEmbeddedElectorService or some such.
3. The code that initializes the elector should be at the same place irrespective of whether it is curator-based or not.
4. 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.

Issue Links

• relates to: YARN-6072 RM unable to start in secure mode
• relates to: YARN-6974 Make CuratorBasedElectorService the default