[
https://issues.apache.org/jira/browse/YARN-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706698#comment-13706698
]
Bikas Saha commented on YARN-521:
---------------------------------
bq. I see. In that case your solution makes sense to me. Essentially, it would
never make sense to call getMatchingRequests at *-level when
locality-relaxation is turned on, right?
It would not make sense to do so but if one does so then the method should
return valid results, right? getMatchingRequests(rack) is less clear wrt if it
makes sense or not but that should also not return invalid results.
The list looks good. Still took me a little while to grok esp. the last 2
points. Lets see how this flies with a different reviewer. In the meanwhile, in
your next patch it would be helpful if you could include each bullet point in a
comment before the code that is performing the check. This includes the first 2
sentences which were not bullet-pointed. I think the second one corresponds to
the ANY list check in the last patch.
Could you please double check that the tests cover these bullet points? A test
for getMatchingRequests() should be easy to add in the existing mocked tests
for the getMatchingRequest() method.
There is one remaining point of confusion.
bq. Requests with locality relaxation off may not coexist at the same priority
as requests with locality relaxation on
Given this, how does one allow relaxing locality for a previously specific node
request. As suggested in an earlier comment, one could remove the previous
request. And then add a new request with the flag allowed. But, if there was
another pre-existing specific request at that priority then this new request
would contradict the above requirement and the check would fail resulting in an
invalid request exception, right?
> Augment AM - RM client module to be able to request containers only at
> specific locations
> -----------------------------------------------------------------------------------------
>
> Key: YARN-521
> URL: https://issues.apache.org/jira/browse/YARN-521
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: api
> Affects Versions: 2.0.3-alpha
> Reporter: Sandy Ryza
> Assignee: Sandy Ryza
> Attachments: YARN-521-1.patch, YARN-521-2.patch, YARN-521-2.patch,
> YARN-521-3.patch, YARN-521.patch
>
>
> When YARN-392 and YARN-398 are completed, it would be good for AMRMClient to
> offer an easy way to access their functionality
--
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
