Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 18 Apr 2014 21:28:16 +0000 (UTC)
From: "Sandy Ryza (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12702989.1395442424497.141510.1397856496110@arcas>
In-Reply-To: <JIRA.12702989.1395442424497@arcas>
References: <JIRA.12702989.1395442424497@arcas>
Subject: [jira] [Commented] (YARN-1864) Fair Scheduler Dynamic Hierarchical
 User Queues
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sandy Ryza commented on YARN-1864:
----------------------------------

Thanks for working on this Ashwin.  I like the approach.

{code}
+            if ("hierarchicalUserQueue".equals(element.getAttribute("name"))) {
+              throw new AllocationConfigurationException(
+                  "hierarchicalUserQueue cannot be a nested rule");
+            }
{code}
Any reason why it can't?

{code}
+        // Verify if the queue returned by the nested rule is an existing leaf queue,
+        // if yes then skip to next rule in the queue placement policy
+        if (queueMgr.exists(queueName)
+            && (queueMgr.getQueue(queueName) instanceof FSLeafQueue)) {
+          return "";
+        }
{code}
The QueuePlacementPolicy isn't in responsible for verifying this.  We expect to hit an error later on if the queue returned by the QueuePlacementPolicy isn't a leaf queue.  This can happen with other rules, for example with the "specified" rule if someone tries to explicitly submit to a parent queue.

Given this, hierarchical queue rule should be terminal if its nested rule is terminal, right?

{code}
+    if (create
+        || (!isNestedRule
+            && configuredQueues.get(FSQueueType.LEAF).contains(queue) 
+                || (isNestedRule && configuredQueues
+                    .get(FSQueueType.PARENT).contains(queue)))) {
{code}
Along similar lines to the previous comment, I don't think we need this logic, or isNestedQueue and FSQueueType, in the queue placement policy.  If the rule places an app in "root.engineering.ashwin" and root.engineering happens to be a leaf or root.ashwin happens to be a parent, we'll end up throwing an error later, which is about the best we can do.  Let me know if there are cases I'm missing or if I'm not thinking this through deeply enough. 

{code}
+   * Places all apps in the specified default queue.
+   * If no default queue is specified or if the specified default queue
+   * doesn't exist, the app is placed in root.default queue
{code}
This has gotten to be a fairly big patch - mind making these changed to the "default" rule in a separate JIRA?

The name "HierarchicalUserQueue" seems a kind of weird to me, as the meaning of "hierarchical" in it is a little vague or maybe already overloaded.  Maybe UserQueueUnderneath, UserQueueInside, or UserQueueBelow?  Any other ideas?

I've got a few stylistic comments in addition to these, but wanted to get this stuff worked out first.

> Fair Scheduler Dynamic Hierarchical User Queues
> -----------------------------------------------
>
>                 Key: YARN-1864
>                 URL: https://issues.apache.org/jira/browse/YARN-1864
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: scheduler
>            Reporter: Ashwin Shankar
>              Labels: scheduler
>         Attachments: YARN-1864-v1.txt, YARN-1864-v2.txt
>
>
> In Fair Scheduler, we want to be able to create user queues under any parent queue in the hierarchy. For eg. Say user1 submits a job to a parent queue called root.allUserQueues, we want be able to create a new queue called root.allUserQueues.user1 and run user1's job in it.Any further jobs submitted by this user to root.allUserQueues will be run in this newly created root.allUserQueues.user1.
> This is very similar to the 'user-as-default' feature in Fair Scheduler which creates user queues under root queue. But we want the ability to create user queues under ANY parent queue.
> Why do we want this ?
> 1. Preemption : these dynamically created user queues can preempt each other if its fair share is not met. So there is fairness among users.
> User queues can also preempt other non-user leaf queue as well if below fair share.
> 2. Allocation to user queues : we want all the user queries(adhoc) to consume only a fraction of resources in the shared cluster. By creating this feature,we could do that by giving a fair share to the parent user queue which is then redistributed to all the dynamically created user queues.


--
This message was sent by Atlassian JIRA
(v6.2#6252)