+++ 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
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"
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.
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.
I like 2) better. Removing "In progress" (option 1) would break the existing alerts on existing JON installations.
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.
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>
Moving to ON_QA as available for test with the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=385149
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/