hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3635) Get-queue-mapping should be a common interface of YarnScheduler
Date Fri, 15 May 2015 20:13:00 GMT

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

Vinod Kumar Vavilapalli commented on YARN-3635:
-----------------------------------------------

Okay, I didn't think you were really meaning the JIRA title literally.

In general, I think we should have a separate component sitting next to ClientService responsible
for mapping apps to queues. I've seen lot more use-cases beyond what we have today in either
of the schedulers - it will be useful to start laying this out with an ultimate intention
to potentially make it an end-user visible abstraction.

Here's what I propose
 - PlacementRule represents a rule with the following interface: {{PlacementAction matches(Application)}}.
Examples includes matching queue-name argument, user-name to queue mapping etc.
 - PlacementAction represents the action to take: simplest is to submit to a queue.
 - PlacementRuleChain: A chain of PlacementRules
 - PlacementRuleChain getting initialized from scheduler specific config files for now
 - A PlacementManager which keeps track of PlacementRuleChain and takes action on incoming
apps

Thoughts?

> Get-queue-mapping should be a common interface of YarnScheduler
> ---------------------------------------------------------------
>
>                 Key: YARN-3635
>                 URL: https://issues.apache.org/jira/browse/YARN-3635
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: scheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-3635.1.patch, YARN-3635.2.patch, YARN-3635.3.patch
>
>
> Currently, both of fair/capacity scheduler support queue mapping, which makes scheduler
can change queue of an application after submitted to scheduler.
> One issue of doing this in specific scheduler is: If the queue after mapping has different
maximum_allocation/default-node-label-expression of the original queue, {{validateAndCreateResourceRequest}}
in RMAppManager checks the wrong queue.
> I propose to make the queue mapping as a common interface of scheduler, and RMAppManager
set the queue after mapping before doing validations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message