Sunil G updated YARN-3216:
    Attachment: 0005-YARN-3216.patch

Hi [~leftnoteasy]
Thank you very much for the comments. Updating patch addressing the comments.

bq.Instead of adding AM-used-resource to parentQueue, I think we may only need 
to calculate AM-used-resource on LeafQueueu and user
Yes, I understood your point. I have kept the changes now only to LeafQueue.

bq.If you agree, could you merge the am-limit computation logic of default 
partition and specific partition?
Yes. It will be better if we have a default am-limit per-queue when 
label-am-limit is not present. Agreeing your point on easiness in configuration 
and to avoid extra *if* checks.

One more point. As per YARN-3265, you have introduced 
{{queueResourceLimitsInfo.getQueueCurrentLimit()}} instead of 
{{queueHeadroomInfo.getQueueMaxCap()}} and this is used in old 
{{getAMResourceLimit}} to see the max-capacity per-queue.

now {{queueResourceLimitsInfo.getQueueCurrentLimit()}} is common per queue. And 
a queue may have 2 or 3 accessible-labels. So I feel I may not be able to use 
this total value always like in {{getAMResourceLimit}}. Hence I think I need to 
calculate max-capacity based on label-percentage per-queue. How do you feel?

> Max-AM-Resource-Percentage should respect node labels
> -----------------------------------------------------
>                 Key: YARN-3216
>                 URL: https://issues.apache.org/jira/browse/YARN-3216
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>            Reporter: Wangda Tan
>            Assignee: Sunil G
>            Priority: Critical
>         Attachments: 0001-YARN-3216.patch, 0002-YARN-3216.patch, 
> 0003-YARN-3216.patch, 0004-YARN-3216.patch, 0005-YARN-3216.patch
> Currently, max-am-resource-percentage considers default_partition only. When 
> a queue can access multiple partitions, we should be able to compute 
> max-am-resource-percentage based on that.

This message was sent by Atlassian JIRA

Reply via email to