hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Vasudev (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-3662) Federation Membership State Store internal APIs
Date Tue, 26 Jul 2016 11:26:20 GMT

    [ 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 them, 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.

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.

> 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


Mime
View raw message