[
https://issues.apache.org/jira/browse/YARN-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064054#comment-15064054
]
Jason Lowe commented on YARN-914:
---------------------------------
[~danzhi] the patch should be against trunk. We always commit first against
trunk and then backport to prior releases in reverse release order (e.g.:
trunk->branch-2->branch-2.8->branch-2.7) so we avoid a situation where a
feature or fix is in a release but disappears in a subsequently released
version. See the [How to
Contribute|http://wiki.apache.org/hadoop/HowToContribute] page for more
information including details on preparing and naming the patch, etc.
Is this implementation inline with the design document on this JIRA or is it
using a different approach?
> (Umbrella) Support graceful decommission of nodemanager
> -------------------------------------------------------
>
> Key: YARN-914
> URL: https://issues.apache.org/jira/browse/YARN-914
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: graceful
> Affects Versions: 2.0.4-alpha
> Reporter: Luke Lu
> Assignee: Junping Du
> Attachments: Gracefully Decommission of NodeManager (v1).pdf,
> Gracefully Decommission of NodeManager (v2).pdf,
> GracefullyDecommissionofNodeManagerv3.pdf
>
>
> When NMs are decommissioned for non-fault reasons (capacity change etc.),
> it's desirable to minimize the impact to running applications.
> Currently if a NM is decommissioned, all running containers on the NM need to
> be rescheduled on other NMs. Further more, for finished map tasks, if their
> map output are not fetched by the reducers of the job, these map tasks will
> need to be rerun as well.
> We propose to introduce a mechanism to optionally gracefully decommission a
> node manager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
