[
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)
