ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <>
Subject [jira] [Created] (AMBARI-9597) Current Alerts Do Not Reflect the Name Change of an Alert Definition
Date Thu, 12 Feb 2015 14:32:13 GMT
Jonathan Hurley created AMBARI-9597:

             Summary: Current Alerts Do Not Reflect the Name Change of an Alert Definition
                 Key: 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

# 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:
  private AlertHistoryEntity createHistory(long clusterId,
      AlertDefinitionEntity definition, Alert alert) {
    AlertHistoryEntity history = new AlertHistoryEntity();
    history.setAlertLabel(alert.getLabel()); // THIS IS WHERE IT GETS SET

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 {{}}.
However, I'd like to get the following question answered:

Do we still want the behavior where changing an alert definition's name (label) only changes
future instances of that alert? 
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

View raw message