[
https://issues.apache.org/jira/browse/YARN-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073428#comment-15073428
]
Advertising
Naganarasimha G R commented on YARN-3215:
-----------------------------------------
Hi [~wangda],
Few concerns on the approach which you mentioned
# My earlier intention was to go with protocol change itself(providing mapping
of each label to head room) rather than sum up the total resources. Any
concerns in doing this way ? or is it before 2.8 we need to get this atleast
done so we will first adopt the approach you suggested ?
# In the approach which you have suggested, First the app needs to specify the
resource requests specifying which partitions they want but IIUC first they
send a empty request to get the head room and then start scheduling internally
what tasks (diff priority) to run. (I am not completely sure about this
correct me if my understanding is wrong). In such cases what should be the
first response ?
> 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
>
> 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
(v6.3.4#6332)
