Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 12 Feb 2015 16:31:12 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12774579.1423751493000.28542.1423758672680@Atlassian.JIRA>
In-Reply-To: <JIRA.12774579.1423751493000@Atlassian.JIRA>
References: <JIRA.12774579.1423751493000@Atlassian.JIRA>
 <JIRA.12774579.1423751493983@arcas>
Subject: [jira] [Commented] (AMBARI-9597) Current Alerts Do Not Reflect the
 Name Change of an Alert Definition
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMBARI-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14318498#comment-14318498 ] 

Hadoop QA commented on AMBARI-9597:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12698436/AMBARI-9597.patch
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 2 new or modified test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number of release audit warnings.

    {color:red}-1 core tests{color}.  The patch failed these unit tests in ambari-server:

                  org.apache.ambari.server.state.cluster.AlertDataManagerTest

Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/1655//testReport/
Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/1655//console

This message is automatically generated.

> Current Alerts Do Not Reflect the Name Change of an Alert Definition
> --------------------------------------------------------------------
>
>                 Key: AMBARI-9597
>                 URL: https://issues.apache.org/jira/browse/AMBARI-9597
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.0.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Critical
>             Fix For: 2.0.0
>
>         Attachments: AMBARI-9597.patch
>
>
> Steps:
> # Go to Alerts page.
> # Open any alert.
> # Change name of alert.
> # Go to host with this alert.
> Result: on host alert page is present alert with old name.
> Here is what I believe the behavior should be:
> - Alert definitions have a "label" value that are used as the human-readable name. When an alert instance comes in, the instance's name (label) is set to that of the current definition. There is no enforced relationship in the database between the definition and instance name. This was a requirement in that changing the name will only change the alert going forward.
> - After changing the definition name, the definition is re-sent to all agents running it and it set to be rescheduled. It's rescheduled with the new name. 
> - When a state change occurs, the following code runs:
> {code:title=AlertReceivedListener.java}
>   private AlertHistoryEntity createHistory(long clusterId,
>       AlertDefinitionEntity definition, Alert alert) {
>     AlertHistoryEntity history = new AlertHistoryEntity();
>     history.setAlertDefinition(definition);
>     history.setAlertInstance(alert.getInstance());
>     history.setAlertLabel(alert.getLabel()); // THIS IS WHERE IT GETS SET
>    ...
> {code}
> So the name will change when a state change occurs and a new history entry gets put in. However, the name will _not_ change if the state doesn't change. If this is undesirable, we can certainly change the name/label when we receive any alert; this is a one-line change in {{AlertReceivedListener.java}}. However, I'd like to get the following question answered:
> {quote}
> Do we still want the behavior where changing an alert definition's name (label) only changes future instances of that alert? 
> {quote}
>  
> Because we currently don't expose history, not changing the name retroactively is not going to be visible at all right now anyway. But in the future we might expose it. Since we do not audit alert definition changes in the operation log, the only way to know when this change happened was to keep the historical items historically accurate. When generating reports, it would be best to keep this data as read-only.
> Therefore, we will only ever change the alerts moving forward.


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