[
https://issues.apache.org/jira/browse/YARN-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13895112#comment-13895112
]
Sandy Ryza commented on YARN-1495:
----------------------------------
While I would argue that preemption is actually more impactful to users than
the option to move apps, as they need to make their applications resilient to
it, it's not the only example. Strict locality and preemption warnings went
into the Fair Scheduler before the Capacity Scheduler, blacklisting went into
the Capacity Scheduler first. The users for moving applications between queues
are cluster administrators, who already need to be aware of the operational
differences between different schedulers. There are many reasons why moving an
application between queues may fail, some of them internal to the scheduler,
such as a violation of resource configurations, some of them external, such as
an application being in a particular state. Using a scheduler that doesn't
support it is just another example.
While having a consistent experience across schedulers is nice, and we should
be very careful to keep the semantics the same when multiple schedulers support
it, I think blocking it in one scheduler because the other doesn't support it
is an unnecessary drag on the pace of development.
> 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)
