Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 833090

Summary: Re-enabling an alert definition clears condition logs for existing conditions
Product: [JBoss] JBoss Operations Network Reporter: Charles Crouch <ccrouch>
Component: Monitoring - AlertsAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: urgent    
Version: JON 3.1.0CC: hbrock, hrupp, jkandasa, jshaughn, loleary
Target Milestone: ER01   
Target Release: JON 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: --- Target Upstream Version:
Embargoed:
Bug Depends On: 830463    
Bug Blocks:    
Attachments:
Description Flags
alert-defination-log none

Description Charles Crouch 2012-06-18 14:48:21 UTC 
+++ 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 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 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 21:22:14 UTC 
I fixed this in master a while ago. It can be tested in any 32 build.
Comment 3 Larry O'Leary 2013-09-06 14:30:40 UTC 
As this is MODIFIED or ON_QA, setting milestone to ER1.
Comment 4 Jeeva Kandasamy 2013-09-20 13:43:35 UTC 
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 15:20:46 UTC 
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 07:38:46 UTC 
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)