[
https://issues.apache.org/jira/browse/AMBARI-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14318594#comment-14318594
]
Hudson commented on AMBARI-9597:
--------------------------------
SUCCESS: Integrated in Ambari-trunk-Commit #1751 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/1751/])
AMBARI-9597 - Current Alerts Do Not Reflect the Name Change of an Alert
Definition (jonathanhurley) (jhurley:
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=cf80e59c6ca5cf3d0a0ba1c53d3dcc3a2be15cdc)
*
ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertReceivedListener.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertResourceProvider.java
*
ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertLifecycleListener.java
*
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertDefinitionResourceProvider.java
*
ambari-server/src/test/java/org/apache/ambari/server/state/alerts/AlertEventPublisherTest.java
*
ambari-server/src/test/java/org/apache/ambari/server/state/cluster/AlertDataManagerTest.java
*
ambari-server/src/main/java/org/apache/ambari/server/events/AlertDefinitionChangedEvent.java
*
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/AlertCurrentEntity.java
*
ambari-server/src/main/java/org/apache/ambari/server/state/alert/AlertDefinitionFactory.java
*
ambari-server/src/main/java/org/apache/ambari/server/state/alert/AlertDefinition.java
*
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/AlertsDAOTest.java
* ambari-server/src/main/java/org/apache/ambari/server/orm/dao/AlertsDAO.java
> 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)
