[
https://issues.apache.org/jira/browse/YARN-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726303#comment-14726303
]
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
(v6.3.4#6332)
