You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Giovanni Matteo Fumarola (JIRA)" <ji...@apache.org> on 2016/03/28 18:03:25 UTC

[jira] [Commented] (YARN-4879) Proposal for a simple (delta) allocate protocol

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

Giovanni Matteo Fumarola commented on YARN-4879:
------------------------------------------------

Thanks [~asuresh] and [~subru] to start this. Everything looks good and easy to read and understand.

Few Comments:
{quote}The allocated Container(s) received as part of the response will have the ID corresponding to the original ResourceRequest for which the RM made the allocation.{quote}
Are you going to add the ResourceRequestId as field of Container?

You guys wrote 
{quote}At high level, we propose to add an ID field to ResourceRequest{quote} after few lines you wrote {quote}The resource-request data structure in RM’s AppSchedulingInfo will be updated to Map<Priority, Map<String, Map<Resource, Map<int, ResourceRequest>>>>.{quote} 
You will not need a int field in the map, because it is already part of the ResourceRequest. Do you want to keep the map ordered by ID?

 
 


> Proposal for a simple (delta) allocate protocol
> -----------------------------------------------
>
>                 Key: YARN-4879
>                 URL: https://issues.apache.org/jira/browse/YARN-4879
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: applications, resourcemanager
>            Reporter: Subru Krishnan
>            Assignee: Subru Krishnan
>         Attachments: SimpleAllocateProtocolProposal-v1.pdf
>
>
> For legacy reasons, the current allocate protocol expects expanded requests which represent the cumulative request for any change in resource constraints. This is not only very difficult to comprehend but makes it impossible for the scheduler to associate container allocations to the original requests. This problem is amplified by the fact that the expansion is managed by the AMRMClient which makes it cumbersome for non-Java clients as they all have to replicate the non-trivial logic. In this JIRA, we are proposing a delta allocate protocol where the AM will need to only specify changes in resource constraints.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)