Bug 1130788

Summary: Event flooding mechanism takes in account deleted events
Product: Red Hat Enterprise Virtualization Manager Reporter: Eli Mesika <emesika>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: acathrow, ecohen, gklein, iheim, lpeer, oourfali, pstehlik, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-26 14:21:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Eli Mesika 2014-08-17 18:22:26 UTC 
Description of problem:
Event flooding mechanism takes in account deleted events.

Starting with 3.5 release we have now an option to remove .Event/Alert from UI. 
Once an Alert is removed, it is marked a "deleted" in the audit_log table and is not returned to the client in next retrivals 

But, to implement the event flooding we use cache mechanism, the removed event is not removed from cache and therefor subsequent event during the event flooding period will not be shown to the user

Version-Release number of selected component (if applicable):


How reproducible:

the problem is 
Steps to Reproduce:
1.Do any action that generates an Event/Alert
2.Dismiss the generated Event/Alert from UI
3.Repeat step 1 withing the flood rate (defined in AuditLogType.java)

Actual results:
The second Event/Alert is suppressed 

Expected results:
The dismissed event should be cleaned from cache and the second generated event from step 3) should be shown 

Additional info:
Comment 1 Oved Ourfali 2014-08-19 06:15:19 UTC 
Note that at the moment, only alerts can be dismissed.
Comment 2 Oved Ourfali 2014-08-26 14:21:00 UTC 
Discussing it offline with Eli, we agreed that the current behavior is okay.
If, for example, we have an alert with flood rate of 30 seconds, and the flow is as follows:
1. Sec 1: Alert is triggered.
2. Sec 2: Alert is dismissed.
3. Sec 3: Alert is triggered again.

In "3" I wouldn't like to see the alert again, only if it is triggered again after 30 seconds.