Junping Du commented on YARN-41:

bq. Initial got the above comment from Vinod about the node state. I feel we 
can proceed here with DECOMMISSIONED state as Vinod suggested and also it will 
not create any compatibility issue.
Sorry. I could miss that comments before. 
OK. I think we are talking about UI and behavior compatibility rather than API 
compatibility. The previous things we can tolerant within major releases but 
the later one we cannot. Both ways doesn't break API compatibility as NodeState 
is marked as UNSTABLE and we were just adding a DECOMMISSIONING state. Isn't it?
The compatibility issue I mentioned above is still there as behavior changes: 
user (and management tools) could feel confused that after this patch, the node 
will show up in the decommission list after normally shutdown. It has been a 
long time that decommission means we want to retire some nodes, so will reject 
the registration of these nodes when they are restarted (unless we explicitly 
remove these nodes from the list), but this is not the case after this patch. I 
agree with Vinod that LOST is pretty far away here, but DECOMMISSIONED is also 
not so ideal I think.

> The RM should handle the graceful shutdown of the NM.
> -----------------------------------------------------
>                 Key: YARN-41
>                 URL: https://issues.apache.org/jira/browse/YARN-41
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: nodemanager, resourcemanager
>            Reporter: Ravi Teja Ch N V
>            Assignee: Devaraj K
>         Attachments: MAPREDUCE-3494.1.patch, MAPREDUCE-3494.2.patch, 
> MAPREDUCE-3494.patch, YARN-41-1.patch, YARN-41-2.patch, YARN-41-3.patch, 
> YARN-41-4.patch, YARN-41-5.patch, YARN-41-6.patch, YARN-41.patch
> Instead of waiting for the NM expiry, RM should remove and handle the NM, 
> which is shutdown gracefully.

This message was sent by Atlassian JIRA

Reply via email to