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

Sandy Ryza commented on YARN-1197:
----------------------------------

bq. I dont think Sandy meant that the AM first tells the NM to decrease the 
size and then the NM informs the RM.
You're right about what I meant.  Though thinking about this more, is there any 
reason a container shrinking needs to get permission from the RM?  Should we 
not treat giving up part of a container in the same way we treat giving up an 
entire container? I.e. that the app unilaterally decides when to do it.  If we 
need to respect properties like yarn.scheduler.minmum-allocation-mb, the 
NodeManagers could pick these up and enforce them by rejecting shrinkings.

bq. The downside is that for the duration of the heartbeat interval, the node 
may get overbooked but that should not be a problem in practice since the 
container would already be using a lower value of resources before the AM asked 
its capacity to be decreased.
Accepting overbooking in this context seems to me like it would open up a bunch 
of race conditions and compromise a bunch of useful assumptions an 
administrator can make about what's running on a node at a given time.  Do the 
uses of container shrinking require such low latency? (which we would also 
achieve by avoiding the round trip to the RM)

> Support changing resources of an allocated container
> ----------------------------------------------------
>
>                 Key: YARN-1197
>                 URL: https://issues.apache.org/jira/browse/YARN-1197
>             Project: Hadoop YARN
>          Issue Type: Task
>          Components: api, nodemanager, resourcemanager
>    Affects Versions: 2.1.0-beta
>            Reporter: Wangda Tan
>         Attachments: yarn-1197.pdf
>
>
> Currently, YARN cannot support merge several containers in one node to a big 
> container, which can make us incrementally ask resources, merge them to a 
> bigger one, and launch our processes. The user scenario is described in the 
> comments.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to