hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wangda Tan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3215) Respect labels in CapacityScheduler when computing headroom
Date Thu, 28 Jan 2016 02:09:39 GMT

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

Wangda Tan commented on YARN-3215:


Thanks for sharing your thoughts, my major concern of excluding NO_LABEL by default is. Applications
could ask nothing in the first AllocateRequest, get headroom back and decide how many resources
to ask, we cannot presume application's behavior. Telling an app: "your headroom is 0" but
there're plenty of resources looks not good enough to me.

The solution for longer term is to add by-partition headroom, it will be a clear protocol
to return what application requested.

I won't strongly against returning only requested headroom to app, but to make it behavior
compatible (previously we returns headroom even if application doesn't ask) and code simpler,
I would prefer to add NO_LABEL by default.


> Respect labels in CapacityScheduler when computing headroom
> -----------------------------------------------------------
>                 Key: YARN-3215
>                 URL: https://issues.apache.org/jira/browse/YARN-3215
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Wangda Tan
>            Assignee: Naganarasimha G R
>         Attachments: YARN-3215.v1.001.patch, YARN-3215.v2.001.patch, YARN-3215.v2.002.patch
> In existing CapacityScheduler, when computing headroom of an application, it will only
consider "non-labeled" nodes of this application.
> But it is possible the application is asking for labeled resources, so headroom-by-label
(like 5G resource available under node-label=red) is required to get better resource allocation
and avoid deadlocks such as MAPREDUCE-5928.
> This JIRA could involve both API changes (such as adding a label-to-available-resource
map in AllocateResponse) and also internal changes in CapacityScheduler.

This message was sent by Atlassian JIRA

View raw message