Wangda Tan commented on YARN-1651:

bq. In other words, the increase expiration logic must remember all ongoing 
increase requests for a container, not just the latest one.
I think we only need to remember *latest confirmed capacity (including 
decreased, confirmed from NM)*. In your example, we only need to remember 4G, 
token2 will overwrite token1 and expiration timout will be reset when second 
increase request approved.

bq. renaming the current ContainerAllocator as AbstractContainerAllocator? 
Anyway, maybe other people will have better suggestions.
This seems better than existing, thoughts? [~jianhe]

bq. I also have another suggestion regarding newlyDecreasedContainers...
This suggestion changes semantics of decreasedContainers in AllocateResponse. 
Currently, both of increasedContainers and decreasedContainers are all added to 
AllocateResponse when approved by RM.
I think it may confuse people if AM waits few cycle to get the 
decreasedContainers. In addition, I cannot see a big value here: AM decreases 
containers just to release resources, it shouldn't care when the resource 
becomes available to YARN, it should decrease resource usage before sending the 
decrease container request to RM. Do you have any use case in your mind that AM 
should know about when/if container is decreased by NM?

> CapacityScheduler side changes to support increase/decrease container 
> resource.
> -------------------------------------------------------------------------------
>                 Key: YARN-1651
>                 URL: https://issues.apache.org/jira/browse/YARN-1651
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager, scheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-1651-1.YARN-1197.patch

This message was sent by Atlassian JIRA

Reply via email to