[
https://issues.apache.org/jira/browse/HADOOP-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698332#action_12698332
]
Hemanth Yamijala commented on HADOOP-5396:
------------------------------------------
JobTracker.refreshQueueAcls():
- Use UserGroupInformation instead of UnixUserGroupInformation.
- The current patch stores an instance of the Configuration object which is
unnecessary. I propose:
-- We remove the refresh() API completely
-- Create a package private refreshAcls(Configuration conf) API
-- Create a new configuration in JobTracker (from the original conf) and send
it to the refreshAcls() API.
-- When we remove the support of the ACLs in the mapred-site.xml, we can modify
the signature of refreshAcls to not take any configuration parameter.
- Indentation in the getQueueAcls method seems inconsistent around the
try..catch block
- "Exception thrown while parsing Configuration" : modify this to "Queue ACLs
could not be refreshed because there was an exception in parsing the
configuration: <Message from exception>. Existing ACLs are retained."
- Better catch Throwable ? There was an instance where the Configuration threw
some uncaught exception in the Job tracker recovery code.
- The changes in initialize are incompatible. Previously if there's a failure
in the initialization code, an exception is thrown back to the JobTracker. I
think it is better to retain this behavior. I think the only change required in
initialize is to factor out the code related to the parsing of ACLs to the new
method getQueueAcls(). From that perspective, I think getQueueAcls() should
simply throw the exception and the handling (conversion to IOException with the
error message) should be done in refreshAcls()
- Tests are still validating with single queue. Having multiple queues and
multiple users (many of whom are dummy, and one valid) will exercise more of
the queuemanager code - just a more conventional way of testing.
- The test for the erroneous file should be a separate test. It's very good
that we are checking the old behavior is retained. It would be nicer to test
that the existing user can submit jobs rather than not submit. So in this test
case, the initial setup can allow the current UGI to submit jobs and verify
after the test that the user can still submit.
> 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
> Attachments: cluster_setup.pdf, commands_manual.pdf,
> hadoop-5396-1.patch, hadoop-5396-2.patch, HADOOP-5396-3-svn.txt,
> HADOOP-5396-4-svn.txt
>
>
> 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.
