[
https://issues.apache.org/jira/browse/YARN-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632630#comment-13632630
]
Chris Douglas commented on YARN-45:
-----------------------------------
bq. ResourceRequest is not actionable in the sense that neither of the
schedulers can currently send a non-empty ResourceRequest to preempt. Both only
do preemption by containers though they have some plumbing to send RR's if they
want to do so. So I am not quite sure what you mean by "We indeed have code
that exercises the ResourceRequest version of it".
A prototype impl against MapReduce responds to {{ResourceRequest}} in the
preempt message. We're currently polishing and splitting that up for review,
but wanted to get consensus on the Yarn changes in case new requirements
required reworking the rest.
An RM impl that includes killing for {{ResourceRequest}} (or {{Resource}}) is a
more invasive change, particularly because (a) the AM needs to reason about
which recently finished containers are included in the message (i.e., it needs
to reason about what the RM knows, so the RM needs to be consistent in what it
tells the AM) and (b) the RM needs to track its previous preemption requests,
timing them out in the context of existing allocations and exited containers
(i.e., decisions to preempt need to incorporate subsequent information).
To get experience before proposing anything drastic, we marked this API as
experimental, wrote the enforcement policy against {{ContainerID}}, and tucked
it behind a pluggable interface. This way, the AM can ignore stale requests for
exited containers and the RM can time out particular containers it asked for
easily; every computed preemption set is bound in a namespace that sidesteps
the most disruptive impl issues on both sides.
bq. By not using location we are implicitly using the "*" location right?
Might as well make it explicit. Non * locations will make sense when affinity
based preemptions occur.
Yes, that's exactly the intent. The policy in YARN-569 doesn't attempt to bias
the preemptions to match the requests in under-capacity queues, but that's a
natural policy to implement against this protocol.
{quote}
The bare-minimum requirement seems:
# RM should notify the AM that a certain amount of resources will need to be
reclaimed (ala SIGTERM).
# Thus, the AM gets an opportunity to *pick* which containers it will sacrifice
to satisfy the RM's requirements.
# Iff the AM doesn't act, the RM will go ahead and terminate some containers
(probably the most-recently allocated ones); ala SIGKILL.
Given the above, I feel that this is a set of changes we need to be
conservative about - particularly since the really simple pre-emption i.e.
SIGKILL alone on RM side is trivial (from an API perspective).
{quote}
Totally agreed. The symmetry of {{ResourceRequest}} in the ask-back is
attractive, but it's not a sufficient condition. To it, I'd add all the
familiar attributes of using them in allocation requests (economy,
expressiveness, versatility). While {{Resource}} covers the current impl, it
leaves little room for related improvements, or even refinements (e.g.,
preferring resources requested by under-capacity queues, prioritizing types of
containers, and time).
The API isn't that complex, but a strict implementation would change the RM
more, adding risk. To mitigate that, but still encourage applications to write
against the richer type while we get experience with it, [~curino]'s
formulation
[above|https://issues.apache.org/jira/browse/YARN-45?focusedCommentId=13628950&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13628950]
seems like a decent set of semantics...
We could add a new type that encodes a subset of the {{ResourceRequest}} type.
It lacks symmetry, but it also allows them to evolve independently.
> Scheduler feedback to AM to release containers
> ----------------------------------------------
>
> Key: YARN-45
> URL: https://issues.apache.org/jira/browse/YARN-45
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Chris Douglas
> Assignee: Carlo Curino
> Attachments: YARN-45.patch, YARN-45.patch
>
>
> The ResourceManager strikes a balance between cluster utilization and strict
> enforcement of resource invariants in the cluster. Individual allocations of
> containers must be reclaimed- or reserved- to restore the global invariants
> when cluster load shifts. In some cases, the ApplicationMaster can respond to
> fluctuations in resource availability without losing the work already
> completed by that task (MAPREDUCE-4584). Supplying it with this information
> would be helpful for overall cluster utilization [1]. To this end, we want to
> establish a protocol for the RM to ask the AM to release containers.
> [1] http://research.yahoo.com/files/yl-2012-003.pdf
--
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
