Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 26 Jul 2016 11:26:20 +0000 (UTC)
From: "Varun Vasudev (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12830362.1431737000000.133707.1469532380661@Atlassian.JIRA>
In-Reply-To: <JIRA.12830362.1431737000000@Atlassian.JIRA>
References: <JIRA.12830362.1431737000000@Atlassian.JIRA> <JIRA.12830362.1431737000428@arcas>
Subject: [jira] [Comment Edited] (YARN-3662) Federation Membership State
 Store internal APIs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 26 Jul 2016 11:26:22 -0000


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

Varun Vasudev edited comment on YARN-3662 at 7/26/16 11:26 AM:
---------------------------------------------------------------

That makes sense. Then let's drop the api piece from the package names? The fact that FedereationStore is an interface should make it clear it's an api.

With regards to the Get/Set - I suspect it's better to follow the convention we follow in the rest of YARN. I think your point about filtering and the package hierarchy are valid, but on the other hand it makes it confusing for folks who've been working with the rest of YARN.

bq. Minimize the wrapper request/response classes as they cause more overhead. I can add them if you still feel it's better to have them?

I think we should add the, irrespective of the overhead. It's hugely helpful to have them, especially for future re-factoring work, if it comes up. Even though these are internal APIs, it will avoid a ton of rework every time someone wants to add a field or some return information. We suffered for not having the equivalent of these wrappers when we had to re-factor the ContainerExecutor classes.


was (Author: vvasudev):
That makes sense. Then let's drop the api piece from the package names? The fact that FedereationStore is an interface should make it clear it's an api.

With regards to the Get/Set - I suspect it's better to follow the convention we follow in the rest of YARN. I think your point about filtering and the package hierarchy are valid, but on the other hand it makes it confusing for folks who've been working with the rest of YARN.

> Federation Membership State Store internal APIs
> -----------------------------------------------
>
>                 Key: YARN-3662
>                 URL: https://issues.apache.org/jira/browse/YARN-3662
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager, resourcemanager
>            Reporter: Subru Krishnan
>            Assignee: Subru Krishnan
>         Attachments: YARN-3662-YARN-2915-v1.1.patch, YARN-3662-YARN-2915-v1.patch, YARN-3662-YARN-2915-v2.patch, YARN-3662-YARN-2915-v3.01.patch, YARN-3662-YARN-2915-v3.patch, YARN-3662-YARN-2915-v4.patch
>
>
> The Federation Application State encapsulates the information about the active RM of each sub-cluster that is participating in Federation. The information includes addresses for ClientRM, ApplicationMaster and Admin services along with the sub_cluster _capability_ which is currently defined by *ClusterMetricsInfo*. Please refer to the design doc in parent JIRA for further details.


--
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