Devaraj K commented on YARN-3225:

Thanks [~djp] for your comments and review. 

bq. There should be no difference for decommission forcelly and previous 
decommission as there should be no side effect to decommission a decommissioned 
node (API marked with Idempotent)

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. 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 the node 

bq. May be it is better to add getDecommissioningNodes() to return a list of 
decommissioning nodes instead of returning a boolean value here? We can print 
it out the decommissioning nodes that haven't finished (or a subset of them if 
large size) when hitting timeout at the end.
It would be good idea to show the decommissioning nodes, I will include this in 
the new patch.

> 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

Reply via email to