Bug 833090 - Re-enabling an alert definition clears condition logs for existing conditions
Re-enabling an alert definition clears condition logs for existing conditions
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Monitoring - Alerts (Show other bugs)
JON 3.1.0
Unspecified Unspecified
urgent Severity high
: ER01
: JON 3.2.0
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On: 830463
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 10:48 EDT by Charles Crouch
Modified: 2015-02-01 18:28 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 830463
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
alert-defination-log (69.46 KB, image/jpeg)
2013-09-20 09:43 EDT, Jeeva Kandasamy
no flags Details

  None (edit)
Description Charles Crouch 2012-06-18 10:48:21 EDT
+++ This bug was initially created as a clone of Bug #830463 +++

Have an alert fire and disable on fire.

Then when the alert has fired, check the condition log in the UI.

Then re-enable the alert definition and check the condition log for the existing alert again - they are gone.

Problem in the source is that somewhere the UI calls 

org.rhq.enterprise.server.alert.AlertDefinitionManagerLocal#updateAlertDefinition

with the last parameter, which is called in the interface "update internals" ,
being true.
In reality that is purging the existing condition logs, which should only happen (if at all) when the conditions change.

Interestingly enough, in the implementation class the parameter is called "purge internals"

--- Additional comment from hrupp@redhat.com on 2012-06-09 18:09:57 EDT ---

To reproduce it is important to edit the alert definition to mark it as active again.

The call in the UI starts here: 
SingleAlertDefinitionView:145
->
org.rhq.enterprise.gui.coregui.client.alert.definitions.ResourceAlertDefinitionsView#commitAlertDefinition
which then adds the hardcoded 'true' to the "purgeInternals" call.

--- Additional comment from hrupp@redhat.com on 2012-06-12 05:27:55 EDT ---

I set this to urgent, as the "clear condition logs" also shows up when the user is e.g. adding a new notification.
Comment 2 Jay Shaughnessy 2013-04-11 17:22:14 EDT
I fixed this in master a while ago. It can be tested in any 32 build.
Comment 3 Larry O'Leary 2013-09-06 10:30:40 EDT
As this is MODIFIED or ON_QA, setting milestone to ER1.
Comment 4 Jeeva Kandasamy 2013-09-20 09:43:35 EDT
Created attachment 800511 [details]
alert-defination-log

Version:
JBoss Operations Network
Version: 3.2.0.ER1
Build Number: 54dd29c:464a643
GWT Version: 2.5.0
SmartGWT Version: 3.0
Browser: Firefos ESR 17.0.7 (RHEL 6.4 x64, Gnome)

I re-enabled the alert definition and checked the condition logs, it's available. however even I modified the the alert definition condition differently, the old logs are available. I was waiting till next purging time. but no change. 

Screen shot is attached.
Comment 5 Heiko W. Rupp 2013-09-20 11:20:46 EDT
I consider this as works as designed, as the sudden vanishing of old logs is not "audit compatible". If a user gets an alert at 3am and later changes the condition, he still wants to know what happened at 3am
Comment 6 Jeeva Kandasamy 2013-09-23 03:38:46 EDT
As per the comment #5, old logs will not be not purged/deleted even-though if we change the alert conditions. Hence I'm moving this issue to verified state.

Version:
JBoss Operations Network
Version: 3.2.0.ER1
Build Number: 54dd29c:464a643
GWT Version: 2.5.0
SmartGWT Version: 3.0
Browser: Firefos ESR 17.0.7 (RHEL 6.4 x64, Gnome)

Note You need to log in before you can comment on or make changes to this bug.