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

Jonathan Hurley updated AMBARI-9597:
------------------------------------
    Attachment: AMBARI-9597.patch

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

Reply via email to