[
https://issues.apache.org/jira/browse/YARN-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677354#comment-13677354
]
Sandy Ryza commented on YARN-752:
---------------------------------
bq. Changing the storage type to set is not desired.
Makes sense to me. I'll revert that part.
bq. What if the RackResolver is improperly initialized
It looks like TableMapping returns NetworkTopology.DEFAULT_RACK whenever it
can't find a node, but ScriptBasedMapping returns null when it encounters
problems. I'll modify the patch to log something and not try to file a
ResourceRequest with a null rack.
bq. The test could probably go into the existing tests for AMRMClient
As unit tests, it seems to me that the closer we can hone in on the
functionality being tested the better. Wrapping the test in a MiniYARNCluster
and other structures used for the AMRMClient lifecycle testing in
TestAMRMClient will make debugging this specific functionality more difficult
in the future.
bq. Also, would be great to make sure that getMatchingRequests() work properly
in this case
I'll try to write a test that verifies this
> In AMRMClient, automatically add corresponding rack requests for requested
> nodes
> --------------------------------------------------------------------------------
>
> Key: YARN-752
> URL: https://issues.apache.org/jira/browse/YARN-752
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: api, applications
> Affects Versions: 2.0.4-alpha
> Reporter: Sandy Ryza
> Assignee: Sandy Ryza
> Attachments: YARN-752.patch
>
>
> A ContainerRequest that includes node-level requests must also include
> matching rack-level requests for the racks that those nodes are on. When a
> node is present without its rack, it makes sense for the client to
> automatically add the node's rack.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
