Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Tue, 11 Apr 2017 18:36:41 +0000 (UTC)
From: "Nate Cole (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.13063281.1491935780000.258982.1491935801565@Atlassian.JIRA>
In-Reply-To: <JIRA.13063281.1491935780000@Atlassian.JIRA>
References: <JIRA.13063281.1491935780000@Atlassian.JIRA> <JIRA.13063281.1491935780926@jira-lw-us.apache.org>
Subject: [jira] [Created] (AMBARI-20736) Allow Potentially Long Running
 Restart Commands To Have Their Own Timeout
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 11 Apr 2017 18:36:45 -0000

Nate Cole created AMBARI-20736:
----------------------------------

             Summary: Allow Potentially Long Running Restart Commands To Have Their Own Timeout
                 Key: AMBARI-20736
                 URL: https://issues.apache.org/jira/browse/AMBARI-20736
             Project: Ambari
          Issue Type: Bug
          Components: ambari-server
            Reporter: Nate Cole
            Assignee: Nate Cole
            Priority: Critical
             Fix For: 2.5.1


During an upgrade of a cluster, some commands are expected to take a very long time depending on what the size of the cluster is and how much data is stored. For example, a NameNode restart with SafeMode exit may take in excess of 30 minutes. On some clusters, this could take less than 1 minute.

Currently today, the only way to adjust these properties is to do so across the board for all commands by editing {{ambari.properties}} and setting {{agent.task.timeout}}. This solution doesn't work very well since the majority of restarts during an upgrade are not on a master component.

There needs to be a way to instruct Ambari that a restart should be allowed to run for a relatively long period of time. 

- Both Java and Python need to be considered here. We don't want Python to give up and return a {{FAILED}} state and we don't want Ambari server to set the task to {{TIMEDOUT}}.

- This can be useful in both normal restarts and upgrade scenarios. 

h3. Upgrade Only
If considering this functionality in the context of an upgrade only, then it is conceivable that this logic can be placed inside of the upgrade XML packs:
{code}
    <service name="HDFS">
      <component name="NAMENODE">
        <upgrade>
          <task xsi:type="restart-task"  timeout="1800"/>
        </upgrade>
{code}

- This would allow future mpacks to be able to control the restart of components. Perhaps this can even be slightly abstracted out:

{code}
    <service name="HDFS">
      <component name="NAMENODE">
        <upgrade>
          <task xsi:type="restart-task"  timeout="upgrade.parameter.master.restart.long"/>
        </upgrade>

upgrade.parameter.slave.restart.short = 300
upgrade.parameter.slave.restart.long = 900
upgrade.parameter.master.restart.short = 1500
upgrade.parameter.master.restart.long = 1800
{code}


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)