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

Karthik Kambatla commented on YARN-1495:
----------------------------------------

I agree with Sandy here. If it were a scheduler feature that is fundamental or 
would bring the RM down if a scheduler doesn't implement, I think it would be a 
good idea to not ship/ merge to branch-2. However, moving applications between 
queues is benign. If the user tries to move using a scheduler that doesn't 
support move yet, it would only say moving apps is not supported. 

It might not be the best analogy, but I think supporting multiple resources in 
the scheduler is similar. CS supported it first, but it was okay for users to 
use related configs while using FS as well; it just didn't take multiple 
resources into account. 

> Allow moving apps between queues
> --------------------------------
>
>                 Key: YARN-1495
>                 URL: https://issues.apache.org/jira/browse/YARN-1495
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: scheduler
>    Affects Versions: 2.2.0
>            Reporter: Sandy Ryza
>            Assignee: Sandy Ryza
>
> This is an umbrella JIRA for work needed to allow moving YARN applications 
> from one queue to another.  The work will consist of additions in the command 
> line options, additions in the client RM protocol, and changes in the 
> schedulers to support this.
> I have a picture of how this should function in the Fair Scheduler, but I'm 
> not familiar enough with the Capacity Scheduler for the same there.  
> Ultimately, the decision to whether an application can be moved should go 
> down to the scheduler - some schedulers may wish not to support this at all.  
> However, schedulers that do support it should share some common semantics 
> around ACLs and what happens to running containers.
> Here is how I see the general semantics working out:
> * A move request is issued by the client.  After it gets past ACLs, the 
> scheduler checks whether executing the move will violate any constraints. For 
> the Fair Scheduler, these would be queue maxRunningApps and queue 
> maxResources constraints
> * All running containers are transferred from the old queue to the new queue
> * All outstanding requests are transferred from the old queue to the new queue
> Here is I see the ACLs of this working out:
> * To move an app from a queue a user must have modify access on the app or 
> administer access on the queue
> * To move an app to a queue a user must have submit access on the queue or 
> administer access on the queue 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to