hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xuan Gong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1459) RM services should depend on ConfigurationProvider during startup too
Date Fri, 07 Feb 2014 08:21:20 GMT

    [ https://issues.apache.org/jira/browse/YARN-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894294#comment-13894294

Xuan Gong commented on YARN-1459:

bq. Server.java: Rename the method name refreshServiceAclWithConfigration() to something else.
It is not clear. May be refreshServiceAclWithLoadedConfiguration().


bq. Similarly, change the name in ServiceAuthorizationManager.


bq. Mark these new methods in both the classes as Private


bq. ConfigurationProvider.getConfigurationInputStream(). Don't have this new API and don't
expose this to outside. Instead modify the current getConfiguration() to take in a multi-arg

removed ConfigurationProvider.getConfigurationInputStream(). Add one more parameter "Configuration
bootstrapConf" to getConfiguration(). Now, it will combine the current bootstrapConf and the
configuration from the FileSystem

bq. Rename the argument name conf in ConfigurationProvider.init(), initInternal(), ConfigurationProviderFactory.getConfigurationProvider(),
FileSystemBasedConfigurationProvider.initInternal() and LocalConfigurationProvider.initInternal()

renamed to bootstrapConf

bq. LocalConfigurationProvider should simply return the bootstrapConf insstead of creating
a new one in getConfiguration().


bq. Change scope of AdminService.refreshServiceAcls() to be private.


bq. Instead of creating RMPolicyProvider objects multiple times in ApplicationMasterService,
ClientRMService etc, create a singleton i nRMPolicyProvider itself and use it everywhere.


bq. Drop the class field useLocalConfigurationProvider in all the classes. you don't need
it anymore. Simply do the instanceOf check right when you need to.


bq. RMContext: Depending on which constructor you use, RMContextImpl may point configurationProvider
to be null. That should never happen.

changed, and will use LocalConfigurationProvider as default.

> RM services should depend on ConfigurationProvider during startup too
> ---------------------------------------------------------------------
>                 Key: YARN-1459
>                 URL: https://issues.apache.org/jira/browse/YARN-1459
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>    Affects Versions: 2.2.0
>            Reporter: Karthik Kambatla
>            Assignee: Xuan Gong
>         Attachments: YARN-1459.1.patch, YARN-1459.2.patch, YARN-1459.3.patch, YARN-1459.4.patch
> YARN-1667, YARN-1668, YARN-1669 already changed RM to depend on a configuration provider
so as to be able to refresh many configuration files across RM fail-over. The dependency on
the configuration-provider by the RM should happen at its boot up time too.

This message was sent by Atlassian JIRA

View raw message