[
https://issues.apache.org/jira/browse/YARN-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117541#comment-15117541
]
Naganarasimha G R commented on YARN-3215:
-----------------------------------------
Thanks for the comments [~wangda],
If we agree upon on the first issue then i think we can correct both issues but
one small concern to consider the first point :-
It depends on the deployment strategy, suppose i have created a partition for
high end machines(more cpu /ram/GPU) and the nodes in this partition compared
to default partition is far less, then in that case head room which is returned
is much more than the app can get if the app( like spark analytic app) is
requesting *only* for the high end machines. In this case i felt HeadRoom
calculations will not be correct, IMHO until we have clear picture how users
want to use headroom in multi partition case better to give headroom as sum as
headrooms of the partitions requested. thoughts?
> 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
(v6.3.4#6332)
