Carlo Curino commented on YARN-6896:

Thanks [~giovanni.fumarola] your answers make sense, and the patch looks good 
to me, with only a couple of things on testing/validation:

# In {{TestFederationInterceptorREST.testSubmitApplication}} (and similar 
methods) you don't check that the request was actually sent to the RM, but only 
that it was book-keeped in the {{FederationStateStore}}, i.e., we only check 
half of the functionality. Since you have your own mock class 
{{MockDefaultFederationInterceptorREST}}, you can have a global static variable 
in the class that you for example increment for each invocation, or you can use 
Mockito {{spy()}} and make sure that one-and-only-one of the 
{{MockDefaultFederationInterceptorREST}} is invoked in normal cases, and that 
for retry scenarios that the right set of invocations is performed (e.g., 
counting separately good/bad SC invocations?). Something along this line would 
strengthen the tests. 
# Did you run this in a live cluster? Not strictly needed, but since the tests 
are "local" to this interceptor a bit of integration validation could help us 
be confident about it.

> Federation: routing REST invocations transparently to multiple RMs (part 1 - 
> basic execution)
> ---------------------------------------------------------------------------------------------
>                 Key: YARN-6896
>                 URL: https://issues.apache.org/jira/browse/YARN-6896
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Giovanni Matteo Fumarola
>            Assignee: Giovanni Matteo Fumarola
>         Attachments: YARN-6896.proto.patch, YARN-6896.v1.patch, 
> YARN-6896.v2.patch
> This JIRA tracks the design/implementation of the layer for routing 
> RMWebServicesProtocol requests to the appropriate RM(s) in a federated YARN 
> cluster.

This message was sent by Atlassian JIRA

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

Reply via email to