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: | UI | Assignee: | Thomas Segismont <tsegismo> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | JON 3.2.1 | CC: | 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
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/ |