hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy Ryza (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1864) Fair Scheduler Dynamic Hierarchical User Queues
Date Fri, 18 Apr 2014 21:28:16 GMT

    [ 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.

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

+        // 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 "";
+        }
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?

+    if (create
+        || (!isNestedRule
+            && configuredQueues.get(FSQueueType.LEAF).contains(queue) 
+                || (isNestedRule && configuredQueues
+                    .get(FSQueueType.PARENT).contains(queue)))) {
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. 

+   * 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
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
> 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

View raw message