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

Reply via email to