[
https://issues.apache.org/jira/browse/HADOOP-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680834#action_12680834
]
Vinod K V commented on HADOOP-5396:
-----------------------------------
Here are the two alternatives I can think of:
- Have queue configuration in hadoop-{default|site}.xml and reload only the
queue related properties. The pro for this proposal is no addition of new files
and the con is that changes in any parameters other than the queue related ones
leads to a confusion - someone trying to see the config file won't be able to
make out the parameters in use by JT and those that have changed.
- Have a separate configuration file for queue configuration. This adds a new
file to be managed but it's very clear as to what the current state of
configuration is. Any change needed in queue configuration can be done
separately without (accidentally) garbling up other parameters.
And two for the way in which the file can be reloaded, whether it's the
hadoop-site.xml or the separate config file:
- Run a thread in JT every so often, and reload the config file if the
modification time changes.
- Have a mradmin utility that asks the JT to reload the configuration. This
involves adding a new RPC in a new protocol that JT would implement.
My preference is to have a separate queue configuration file with a mradmin
utility to reload the configuration. I think it's clean this way. Thoughts?
> Queue ACLs should be refreshed without requiring a restart of the job tracker
> -----------------------------------------------------------------------------
>
> Key: HADOOP-5396
> URL: https://issues.apache.org/jira/browse/HADOOP-5396
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Hemanth Yamijala
> Assignee: Vinod K V
>
> In large shared deployments of the M/R clusters, it is normal that new users
> will periodically want to get access to some queues on the M/R framework.
> Requiring a JT restart for each such change is operationally inconvenient and
> seems an overkill. There should be a way for updating ACLs with new users
> without requiring a JT restart.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
