Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1664786422.1239645374976.JavaMail.jira@brutus>
Date: Mon, 13 Apr 2009 10:56:14 -0700 (PDT)
From: "Hemanth Yamijala (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-5396) Queue ACLs should be refreshed
 without requiring a restart of the job tracker
In-Reply-To: <1273988453.1236179036203.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698462#action_12698462 ] 

Hemanth Yamijala commented on HADOOP-5396:
------------------------------------------

Close.. but little work still.

- I still feel QueueManager.initialize() is doing more than it should. I think this snippet of code is sufficient:
{code}
  private void initialize(Configuration conf) {
    aclsEnabled = conf.getBoolean("mapred.acls.enabled", false);
    String[] queues = conf.getStrings("mapred.queue.names", 
                                  new String[] {JobConf.DEFAULT_QUEUE_NAME});
    addToSet(queueNames, queues);
    aclsMap = getQueueAcls(conf);
  }
{code}

Does this not seem to work ?

- In the current patch no warning is being printed if the queue ACLs are present in the mapred-site.xml on initialization. I think the problem will be fixed if we move the call to check deprecation inside the getQueueAcls method, just before the QUEUE_ACLS_FILE_NAME resource is added. I also think the array of queue names can be constructed in the getQueueAcls() method itself. So its signature will look like this:
{code}
 private HashMap<String, AccessControlList> getQueueAcls(
                                              Configuration conf)  {
{code}

- The test for the invalid file is printing an incorrect message. It says "User Job Submission Succeeded before refresh.", shouldn't it be failed ?
- Another point is that the test should have a fail() call after the refreshAcls(). This will ensure the exception is actually thrown, else the test will fail.

- Commands setup documentation still says refreshQueueAcl.

> 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-3.patch, 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.