Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Thu, 30 Jul 2015 14:38:05 +0000 (UTC)
From: "Hong Zhiguo (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12848502.1437647625000.330792.1438267085182@Atlassian.JIRA>
In-Reply-To: <JIRA.12848502.1437647625000@Atlassian.JIRA>
References: <JIRA.12848502.1437647625000@Atlassian.JIRA>
 <JIRA.12848502.1437647625747@arcas>
Subject: [jira] [Updated] (YARN-3965) Add starup timestamp for nodemanager
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/YARN-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hong Zhiguo updated YARN-3965:
------------------------------
    Attachment: YARN-3965-3.patch

> Add starup timestamp for nodemanager
> ------------------------------------
>
>                 Key: YARN-3965
>                 URL: https://issues.apache.org/jira/browse/YARN-3965
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: nodemanager
>            Reporter: Hong Zhiguo
>            Assignee: Hong Zhiguo
>            Priority: Minor
>         Attachments: YARN-3965-2.patch, YARN-3965-3.patch, YARN-3965.patch
>
>
> We have startup timestamp for RM already, but don't for NM.
> Sometimes cluster operator modified configuration of all nodes and kicked off command to restart all NMs.  He found out it's hard for him to check whether all NMs are restarted.  Actually there's always some NMs didn't restart as he expected, which leads to some error later due to inconsistent configuration.
> If we have startup timestamp for NM,  the operator could easily fetch it via NM webservice and find out which NM didn't restart, and take mannaul action for it.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)