[
https://issues.apache.org/jira/browse/YARN-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585677#comment-13585677
]
Bikas Saha commented on YARN-392:
---------------------------------
@Sandy
It would be per priority like I mentioned in my explanation. Or else it wont be
useful for a mixed scenario like you mention in 1)
Your example 2 highlights the inherent lossy nature of the protocol and is
orthogonal to this jira. e.g. take the mapreduce case. and say map 1 is local
to node1 and node2 while map2 is local to node3 and node4. They also have rack
and * preferences. nothing prevents the RM from allocating node1 and node2 to
the app if node2 and node3 happen to be on the same rack. The app has to cancel
node2 from its resource map as soon as it satisfies map1 with node1. That is
why we need (and have) a method to release unwanted containers. In the general
case, distributed allocation (where request and grant are across nodes) is
subject to race conditions.
> Make it possible to schedule to specific nodes without dropping locality
> ------------------------------------------------------------------------
>
> Key: YARN-392
> URL: https://issues.apache.org/jira/browse/YARN-392
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Sandy Ryza
> Attachments: YARN-392.patch
>
>
> Currently its not possible to specify scheduling requests for specific nodes
> and nowhere else. The RM automatically relaxes locality to rack and * and
> assigns non-specified machines to the app.
--
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
