[
https://issues.apache.org/jira/browse/YARN-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662276#comment-13662276
]
Bikas Saha commented on YARN-392:
---------------------------------
[~tucu00] We were in agreement with the delayed locality relaxation approach
where we wanted to add a time interval that specifies how long to wait before
doing the relaxation.
https://issues.apache.org/jira/browse/YARN-392?focusedCommentId=13639491&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13639491
At that point there was no ambiguity about the meaning of the new field. It was
then suggested that implementing the time interval version of it would be hard
and so we decided to do the boolean version of it. Now the boolean has an
ambiguity because in a non-intended way it seems like it would support black
listing too. Boolean by definition implies an inverse relation.
[~sandyr] I meant blacklisting on an app level (and not cluster wide) vs
blacklisting at different RRs.
I am not advocating that using the non-intended aspect of the boolean is not
useful. What I dont want is additional ambiguity and overload in the protocol.
If we can resolve the ambiguity/overload with a single boolean then it would be
great to see a crisp definition of it. If not, and if we want to use a boolean
based per RR blacklisting then perhaps we can add a relaxLocality flag which
affects only locality relaxation and a blacklist flag that does blacklisting
per RR. These may seem duplicate but in the users mind and in the scheduler
code their definitions are crisp. The new flag would be a different jira though.
The way the code is written in the last patch I saw, the only change would be
to not check the flag at the node level. As far as the sanity checking is
concerned, it would be great to have these and other sanity checks I have
already mentioned in previous comments. Sandy responded that those checks would
be unnecessary overhead.
> Make it possible to specify hard locality constraints in resource requests
> --------------------------------------------------------------------------
>
> 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-1.patch, YARN-392-2.patch, YARN-392-2.patch,
> YARN-392-2.patch, YARN-392-3.patch, YARN-392-4.patch, 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
