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-3225) New parameter or CLI for decommissioning node gracefully in RMAdmin CLI
Date Wed, 25 Mar 2015 15:52:54 GMT

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

Junping Du commented on YARN-3225:

Thanks for quickly response, [~devaraj.k]!
bq. If we make the refreshNodesForcefully as same as refreshNodes() API, there could be a
chance of becoming node state incosistent if the hosts file updated with the newnodes or removal
of existing nodes after the refreshNodesGracefully and before the refreshNodesForcefully.
+1. That's good point.

bq. I feel we need to have difference that refreshNodes()/refreshNodesGracefully() should
read the hosts file and refreshNodesForcefully() would not read the hosts file and only move
Agree that this sounds better. However, as my suggestion above, we can still keep the same
Admin API. In AdminService side, we can handle request (not boolean value now, could be a
new enum :)) in three cases separately.

> New parameter or CLI for decommissioning node gracefully in RMAdmin CLI
> -----------------------------------------------------------------------
>                 Key: YARN-3225
>                 URL: https://issues.apache.org/jira/browse/YARN-3225
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Junping Du
>            Assignee: Devaraj K
>         Attachments: YARN-3225-1.patch, YARN-3225.patch, YARN-914.patch
> New CLI (or existing CLI with parameters) should put each node on decommission list to
decommissioning status and track timeout to terminate the nodes that haven't get finished.

This message was sent by Atlassian JIRA

View raw message