[ 
https://issues.apache.org/jira/browse/YARN-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628358#comment-13628358
 ] 

Alejandro Abdelnur commented on YARN-45:
----------------------------------------

Carlo, I may be missing something then.

>From your description I'm understanding that a PreemptRequest could contain 
>either Set<ContainerID> or Set<ResourceRequest> but not both.

If I'm correct with this assumption, then if the RM chooses to send 
Set<ContainerID> then  we are back to square one where the RM is deciding what 
to kill, it just giving a heads up.

If the idea is that the RM will send PreemptRequest containing both 
Set<ContainerID> and Set<ResourceRequest> which are equivalent (just 2 ways of 
expressing the same amount of resources), then it seems OK. In this case, the 
Set<ContainerID> is just a convenience fo the AM not to go and dig its internal 
data structures. But you seem to indicate this is not the case in your second 
last paragraph.

I'd argue that the Set<ContainerID> is just an early warning, it does not 
delegate the choice to the AM. The fact that the AM could decide to get rid of 
another container in the same location and make this preemption to go away 
seems twisted.

Regardless of the convenience because of the implementation, I don't think the 
RM should cares which containers the AM chooses to release but the amount of 
resources.

My specific use case is that that the AM should get an amount of preempt 
resources and decide which containers are best to release.

                
> Scheduler feedback to AM to release containers
> ----------------------------------------------
>
>                 Key: YARN-45
>                 URL: https://issues.apache.org/jira/browse/YARN-45
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: resourcemanager
>            Reporter: Chris Douglas
>            Assignee: Carlo Curino
>         Attachments: YARN-45.patch
>
>
> The ResourceManager strikes a balance between cluster utilization and strict 
> enforcement of resource invariants in the cluster. Individual allocations of 
> containers must be reclaimed- or reserved- to restore the global invariants 
> when cluster load shifts. In some cases, the ApplicationMaster can respond to 
> fluctuations in resource availability without losing the work already 
> completed by that task (MAPREDUCE-4584). Supplying it with this information 
> would be helpful for overall cluster utilization [1]. To this end, we want to 
> establish a protocol for the RM to ask the AM to release containers.
> [1] http://research.yahoo.com/files/yl-2012-003.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to