[AMBARI-9597] Current Alerts Do Not Reflect the Name Change of an Alert Definition

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.0.0
• Fix Version/s: 2.0.0
• Component/s: ambari-server
• Epic Link: Alerts Redesign
• Assignee: Jonathan Hurley
• Reporter: Jonathan Hurley
• Created: 12/Feb/15 14:31
• Updated: 12/Feb/15 17:38
• Resolved: 12/Feb/15 16:40

Description

Steps:

1. Go to Alerts page.
2. Open any alert.
3. Change name of alert.
4. 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:
  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
     ...
  

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:

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.

Issue Links

• links to: Reviewboard