[
https://issues.apache.org/jira/browse/YARN-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14068545#comment-14068545
]
Jason Lowe commented on YARN-1198:
----------------------------------
We need to worry about headroom as a report of resources that can be allocated
if requested. If the AM cannot currently allocate any containers then the
headroom should be reported as zero. I think "guaranteed headroom" is a
separate JIRA and not necessary to solve the deadlock issues surrounding the
current headroom reporting.
bq. Because in a dynamic cluster, the number can change rapidly, it is possible
that a cluster is fulfilled by another application just happens one second
after the AM got the "available headroom".
Sure, this can happen. However on the next heartbeat the headroom will be
reported as less than it was before, and the AM can take appropriate action. I
don't see this as a major issue at least in the short-term. Telling an AM
repeatedly that it can allocate resources that will never be allocated in
practice is definitely wrong and needs to be fixed.
bq. And also, this field can not solve the deadlock problem as well, a
malicious application can ask much more resource of this, or a careless
developer totally ignore this field.
A malicious application cannot cause another application to deadlock as long as
the YARN scheduler properly enforces user limits and properly reports the
headroom to applications. It seems to me the worst case is an application
hurts itself, but since the entire application can be custom user code there's
not much YARN can do to prevent that.
bq. The only valid solution in my head is putting such logic into scheduler
side, and enforce resource usage by preemption policy.
The problem is that the scheduler does not, and IMHO should not, know the
details of the particular application. For example, let's say an application's
headroom goes to zero but is has outstanding allocation requests. Should the
YARN scheduler automatically preempt something when this occurs? If so which
container does it preempt? These are questions an AM can answer optimally,
including an answer of preempting nothing (e.g.: task is completing
imminently), while I don't see how the YARN scheduler can make good decisions
without either putting application-specific logic in the YARN scheduler or
having the YARN scheduler defer to the AM to make the decision. Reporting the
headroom to the AM enables the AM to make an application-optimal decision of
what to do, if anything, when the available resources to the application
changes.
> Capacity Scheduler headroom calculation does not work as expected
> -----------------------------------------------------------------
>
> Key: YARN-1198
> URL: https://issues.apache.org/jira/browse/YARN-1198
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Omkar Vinit Joshi
> Assignee: Omkar Vinit Joshi
> Attachments: YARN-1198.1.patch
>
>
> Today headroom calculation (for the app) takes place only when
> * New node is added/removed from the cluster
> * New container is getting assigned to the application.
> However there are potentially lot of situations which are not considered for
> this calculation
> * If a container finishes then headroom for that application will change and
> should be notified to the AM accordingly.
> * If a single user has submitted multiple applications (app1 and app2) to the
> same queue then
> ** If app1's container finishes then not only app1's but also app2's AM
> should be notified about the change in headroom.
> ** Similarly if a container is assigned to any applications app1/app2 then
> both AM should be notified about their headroom.
> ** To simplify the whole communication process it is ideal to keep headroom
> per User per LeafQueue so that everyone gets the same picture (apps belonging
> to same user and submitted in same queue).
> * If a new user submits an application to the queue then all applications
> submitted by all users in that queue should be notified of the headroom
> change.
> * Also today headroom is an absolute number ( I think it should be normalized
> but then this is going to be not backward compatible..)
> * Also when admin user refreshes queue headroom has to be updated.
> These all are the potential bugs in headroom calculations
--
This message was sent by Atlassian JIRA
(v6.2#6252)
