[
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: [email protected]
For additional commands, e-mail: [email protected]
