hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Junping Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-311) Dynamic node resource configuration: core scheduler changes
Date Mon, 16 Dec 2013 15:23:08 GMT

    [ https://issues.apache.org/jira/browse/YARN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849230#comment-13849230
] 

Junping Du commented on YARN-311:
---------------------------------

Thanks Bikas for comments! Please see my reply:
bq. Sorry for coming in so late on this.
No problem. Given this patch is already commited, I will address them in separated JIRAs.
Make sense?
bq. Some javadoc on ResourceOption would be helpful. Explanation of the context of dynamic
resource changes on a node and resulting over-commitment of resources would be good. ResourceOption
as a name did not make it clear to me the nature/use of the object.
Yes. Vinod had similar comments in YARN-312. Will file a JIRA [let's call it JIRA-1] to handle
naming issue as well as more document on over-commitment cases.
bq.  Would it be less error prone if we compared the total size of schedulernode and rmnode
instead of the difference in their current available capacity? Also, in the update to the
node. Why are we updating only the availableResource and skipping totalresource? Total resource
is used during scheduling decisions.
That's nice catch! When this patch was developed, there is actually no total capacity in scheduler
node (it is get involved in YARN-957, checked in several months ago) so comparing RMNode's
total resource with schedulerNode'S (used resource + available resource) is the only choice
at that time. I will file another JIRA [let's call it JIRA-2] to address this.
bq.  The current impl of addTo will work for both +ve and -ve deltas but given that there
are addTo and subtractFrom methods, its not clear to me if that is a coincidence or not. Ideally
there should have been one update method that by definition should handle +ve and -ve updates.
This is to handle some complicated cases. i.e. increase CPU resource while decrease Memory
resource. Shall we use addTo or subtractFrom? Keep it simple and stupid like here may make
more sense?
bq. Since changing the resource on a node would be an admin/service operation, why are we
adding resourceOption to the rmnode and setting it in registernodemanager? Similarly, why
are we trying to update the node on every heartbeat. I was expecting that whenever the node
resource would be updated then an event would be sent to the scheduler. Upon receiving the
event, the scheduler would make a one time update of the internal book-keeping objects.
I think RMNode should be updated as resource view should be consistent across the system or
it will cause system/user get confused. That's a nice suggestion to have resource update event
on schedulerNode. Vinod has similar comments on RMNode update event, and I will address these
comments with filing [JIRA-3].
bq. Again, I apologize for coming in so late on this jira.
Never mind. Good comments are never too late. Thanks for this, Bikas!

> Dynamic node resource configuration: core scheduler changes
> -----------------------------------------------------------
>
>                 Key: YARN-311
>                 URL: https://issues.apache.org/jira/browse/YARN-311
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager, scheduler
>            Reporter: Junping Du
>            Assignee: Junping Du
>             Fix For: 2.4.0
>
>         Attachments: YARN-311-v1.patch, YARN-311-v10.patch, YARN-311-v11.patch, YARN-311-v12.patch,
YARN-311-v12b.patch, YARN-311-v13.patch, YARN-311-v2.patch, YARN-311-v3.patch, YARN-311-v4.patch,
YARN-311-v4.patch, YARN-311-v5.patch, YARN-311-v6.1.patch, YARN-311-v6.2.patch, YARN-311-v6.patch,
YARN-311-v7.patch, YARN-311-v8.patch, YARN-311-v9.patch
>
>
> As the first step, we go for resource change on RM side and expose admin APIs (admin
protocol, CLI, REST and JMX API) later. In this jira, we will only contain changes in scheduler.

> The flow to update node's resource and awareness in resource scheduling is: 
> 1. Resource update is through admin API to RM and take effect on RMNodeImpl.
> 2. When next NM heartbeat for updating status comes, the RMNode's resource change will
be aware and the delta resource is added to schedulerNode's availableResource before actual
scheduling happens.
> 3. Scheduler do resource allocation according to new availableResource in SchedulerNode.
> For more design details, please refer proposal and discussions in parent JIRA: YARN-291.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message