[ https://issues.apache.org/jira/browse/YARN-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15726920#comment-15726920 ]
Jian He commented on YARN-5709: ------------------------------- bq. yarn.resourcemanager.ha.automatic-failover.embedded For the original hadoop-common's elector, I agree we should keep using this config, otherwise, it's incompatible. But for the curator-based implementation. I feel we can avoid this config. One less config is one step easier to config HA. This config looks like a placeholder for future implementation only, which can never be set to false as of now. IMHO, instead, a ZK-FC-based-elector config can be added later if it's really implemented in the future. bq. Any reason we are not replacing the implementation? Do we just want to be safe and have a workaround in case the curator-based elector turns out to broken? Yeah, just intends to be safe. bq. If that is the case, the config that determines the implementation should be removed in a subsequent release and accordingly be called out @Unstable. We should likely not list it in yarn-default.xml. agree bq. If we do decide on moving the initialization, we should move it for both implementations and not just one. Agree we can move both. bq. However, if we were to implement a ZKFC-based elector, that would have to depend on the AdminService to affect any transitions at all. I believe Bikas has recommended we keep the same code path irrespective of whether leader election is embedded. I see merit to that argument. Didn't actually get the argument about keeping the same code path... If EmbeddedElectorService is moved outside of AdminService, it still uses the same code path. EmbeddedElectorService -> AdminService -> transitionToActive/Standby. For ZKFC-based elector, it's the same. IIUC, whether EmbeddedElectorService is initialized inside AdminService or outside does not affect reusing the same code path. And conceptually EmbeddedElectorService does not look like a sub-service of AdminService.. > Cleanup leader election related configuration mess > -------------------------------------------------- > > 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: Daniel Templeton > Priority: Blocker > > 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