[
https://issues.apache.org/jira/browse/YARN-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387381#comment-15387381
]
Varun Vasudev commented on YARN-3662:
-------------------------------------
Thanks for the patches [~subru]! My thoughts on the patch -
1)
{code}
+ public FederationSubClusterId registerSubCluster(
+ FederationSubClusterInfo subClusterInfo) throws YarnException;
{code}
{code}
+ public FederationSubClusterHeartbeatResponse subClusterHeartbeat(
+ FederationSubClusterInfo subClusterInfo) throws YarnException;
{code}
{code}
+ public FederationSubClusterInfo getSubClusterInfo(
+ FederationSubClusterId subClusterId) throws YarnException;
{code}
{code}
+ public Map<FederationSubClusterId, FederationSubClusterInfo>
getAllSubClustersInfo()
+ throws YarnException;
{code}
These functions should follow the Request/Response structure. i.e take a
request object and return a response object. e.g registerSubCluster should take
a RegisterSubClusterRequest object and return a RegisterSubClusterResponse.
Similarly with all the other cases.
2)
{code}
+ public FederationSubClusterInfo getSubClusterInfo(
+ FederationSubClusterId subClusterId) throws YarnException;
{code}
Rename to getSubCluster? No need for info
3)
{code}
+ public Map<FederationSubClusterId, FederationSubClusterInfo>
getAllSubClustersInfo()
+ throws YarnException;
{code}
Rename to getSubClusters - no need for all or info. It would also be useful to
take a GetSubClustersRequest object so that we can add support for filters in
the future.
4)
Rename SC_DEREGISTERED to SC_UNREGISTERED
5)
In FederationSubClusterHeartbeatRequest#newInstance, rename {code}
FederationSubClusterHeartbeatRequest subClusterInfo {code} to request
6)
{code}
+ @Private
+ @Unstable
+ public abstract void setCapability(String capability);
{code}
I'm not sure String is the right way to express capability but I can't think of
a good alternative for now. Maybe we should use the Resource class to express
capability?
7)
{code}
+ @Override
+ public int hashCode() {
+ return getSubClusterId().hashCode();
+ }
{code}
In HeartbeatRequest and FederationSubClusterInfo , the hashcode function should
take into account everything equals takes into account.
8)
This is more a code organization comment. Maybe we should move api pieces into
hadoop-yarn-api? Right now the API and the implementation are in
hadoop-server-common but it looks like the API pieces will be widely used.
Please correct me if I'm wrong.
> Federation Membership State 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]
