Bug 1066947

Summary: Alert being triggered twice if the Operation Execution has the status set to In Progress
Product: [JBoss] JBoss Operations Network Reporter: Sunil Kondkar <skondkar>
Component: UIAssignee: Thomas Segismont <tsegismo>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: JON 3.2.1CC: ahovsepy, hrupp, jkremser, jshaughn, loleary, skondkar, tsegismo
Target Milestone: ER03   
Target Release: JON 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 919516 Environment:
Last Closed: 2014-12-11 14:02:38 UTC 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: 919516    
Bug Blocks:    

Description Sunil Kondkar 2014-02-19 11:06:48 UTC
+++ This bug was initially created as a clone of Bug #919516 +++

Description of problem:
If an alert has a condition of type "Operation Execution" and the status field is set to "In Progress", then the alert get triggered twice if I the op. is run

Version-Release number of selected component:
4.6.0-SNAPSHOT

How reproducible:
always


Steps to Reproduce:
1. create an alert on "RHQ Agent" resource

2. add a new condition of type Operation Execution, select the op. "Execute Availability Scan" (for instance) and set the status to "In Progress"

3. schedule the selected operation ("Execute Availability Scan" in our case) on the RHQ Agent resource

4. observe the alerts/history tab
  


Actual results:
the alert is there twice

Expected results:
the alert is there only once

--- Additional comment from Jirka Kremser on 2013-12-04 12:00:40 EST ---

it's working in master

Comment 1 Sunil Kondkar 2014-02-19 11:09:12 UTC
Added a test for alert in progress condition:

To run the test:
git clone https://github.com/RedHatQE/jon-tests.git
cd jon-tests/alerts
nosetests -a "single,control"

Comment 4 Sunil Kondkar 2014-08-28 08:18:11 UTC
The test fails on JON 3.3 ER01 build.

Link to the test run:
http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/rhq-core-alerts-python-test/397/testReport/tests.testsingle/FireControlAlert/test_operationStatusInProgressRealPlatform/

Also tested manually on Version :3.3.0.ER01 Build Number :23b3476:f3aa7e7
The history tab displays two alerts for In Progress alert condition when the operation is executed.

Comment 5 Thomas Segismont 2014-08-28 11:54:18 UTC
I could reproduce as well on a 3.3 branch build. Here's the issue.

When the operation is scheduled an operation history entity is persisted, because the operation entity needs it. The first alert is fired at this moment.

Later, a quartz job remotely invokes the operation on the agent. When the job starts, it updates the operation history to indicate the actual start time. Then the second alert is fired.

I can see two ways to improve the situation.

1. Given that the alert condition editor says "Specify the result that must occur when the selected operation is executed in order to trigger the condition.", we could simply remove the "In progress" status from the expected value combo box. "In progress" is not an operation *result*, it's just an operation execution status.

The drawback is that users won't be able to be alerted on operations being started any more.

2. Change the wording of the alert condition editor to indicate that he's going to monitor an operation status change. And change the alert condition evaluation code so that only changing status fires an alert.

I tend to prefer the second solution but I'd like to hear Larry's input.

Comment 6 Jirka Kremser 2014-08-28 13:24:46 UTC
I like 2) better. Removing "In progress" (option 1) would break the existing alerts on existing JON installations.

Comment 7 Thomas Segismont 2014-09-03 11:47:48 UTC
Fixed in master

commit c09e9440f19b97dd6b3a353fc3880afefd4d3222
Author: Thomas Segismont <tsegismo>
Date:   Wed Sep 3 13:46:21 2014 +0200
    
    Changed the wording of the alert condition editor to indicate the user is going to monitor an operation status change.
    Call #notifyAlertConditionCacheManager only if the operation history status has changed.

Comment 8 Jay Shaughnessy 2014-09-11 18:32:38 UTC
This fix looks good to me.

release/jon3.3.x commit b013ec236ba523462bfcaca7de08d470300ae372
Author: Thomas Segismont <tsegismo>
Date:   Wed Sep 3 13:46:21 2014 +0200

    (cherry picked from commit c09e9440f19b97dd6b3a353fc3880afefd4d3222)
    Signed-off-by: Jay Shaughnessy <jshaughn>

Comment 9 Simeon Pinder 2014-09-17 02:49:29 UTC
Moving to ON_QA as available for test with the following brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=385149

Comment 10 Sunil Kondkar 2014-09-17 11:11:09 UTC
Verified on version : 3.3.0.ER03 build number : 4aefe39:44e33a4

The test is passed on JON 3.3 ER03 build.

Link to the test run:

http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/rhq-core-alerts-python-test/437/testReport/tests.testsingle/FireControlAlert/test_operationStatusInProgressRealPlatform/