[
https://issues.apache.org/jira/browse/YARN-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356774#comment-14356774
]
Junping Du commented on YARN-3225:
----------------------------------
bq. Here what would happen to the decommissioning node if the RMAdmin issued
refreshNodeGracefully() and gets terminated(exited) before issuing the
'refreshNode forcefully'? This can be done by doing Ctrl+C on the command
prompt. The Node will be in decommissioning state forever and becomes unusable
for new containers allocation.
>From v3 version of proposal in umbrella JIRA, "If CLI get interrupted, then it
>won’t keep track of timeout to forcefully decommissioned left nodes. However,
>nodes in “DECOMMISSIONING” will still get terminated later (after running apps
>get finished) except admin call recommission CLI on these nodes explicitly."
>The node in decommissioning state are terminated for 2 trigger events, one is
>timeout and the other is all application (on that node) get finished (will be
>covered in YARN-3212). We can document what's that means if user do Ctrl +C to
>gracefully decommissioning CLI. If application (like LRS) never ends in this
>situation, then user need to refresh these node forcefully (or gracefully with
>timeout but not interrupt). Make sense?
> 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.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
(v6.3.4#6332)
