Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 19 May 2016 12:51:13 +0000 (UTC)
From: "Junping Du (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12756276.1416359850000.235639.1463662273833@Atlassian.JIRA>
In-Reply-To: <JIRA.12756276.1416359850000@Atlassian.JIRA>
References: <JIRA.12756276.1416359850000@Atlassian.JIRA> <JIRA.12756276.1416359850465@arcas>
Subject: [jira] [Commented] (YARN-2877) Extend YARN to support distributed
 scheduling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 19 May 2016 12:51:15 -0000


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

Junping Du commented on YARN-2877:
----------------------------------

bq. Thanks for investigation Wangda Tan and Junping Du
The most investigation work is done by Wangda. We should put all credit to him. :)

bq. Not sure if I understand correctly, are you proposing that we should NOT declare new fields in sequence ? for eg. if the last field index is 10 for a struct in trunk, if we want to add a new field, we should set it as something like 15 and not 11 ?
I think what Wangda's propose above is: next time when we meet the same situation: patch 1 go to trunk first but not branch-2, patch 2 need to go to branch-2 and they all change field of the same proto (assume patch 1's field id = 2, patch 2's field id =3 on trunk). We don't necessary to adjust the sequence in trunk any more like we do it earlier. Instead, on branch-2, we can keep patch 2's filed Id =3 and skip id = 2 which is reserved for patch 1 to commit to branch-2 in future. 
That can save our lives from possible incompatible commits due to branch differences.

> Extend YARN to support distributed scheduling
> ---------------------------------------------
>
>                 Key: YARN-2877
>                 URL: https://issues.apache.org/jira/browse/YARN-2877
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: nodemanager, resourcemanager
>            Reporter: Sriram Rao
>            Assignee: Konstantinos Karanasos
>         Attachments: distributed-scheduling-design-doc_v1.pdf
>
>
> This is an umbrella JIRA that proposes to extend YARN to support distributed scheduling.  Briefly, some of the motivations for distributed scheduling are the following:
> 1. Improve cluster utilization by opportunistically executing tasks otherwise idle resources on individual machines.
> 2. Reduce allocation latency.  Tasks where the scheduling time dominates (i.e., task execution time is much less compared to the time required for obtaining a container from the RM).
>  


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

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org