Bug 577217 - (jon24-alert-notify) Support for pluggable alert notifications
Support for pluggable alert notifications
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: No Component (Show other bugs)
unspecified
All Linux
high Severity high (vote)
: ---
: ---
Assigned To: Joseph Marques
Sudhir D
:
Depends On: 562816 570161 573815 585846 585849 586099 586103 586104 586131 590575 591246 591485 593218 593223 593282 599691 602788 607548 607898 614845
Blocks: jon24-features
  Show dependency treegraph
 
Reported: 2010-03-26 09:28 EDT by Charles Crouch
Modified: 2015-02-01 18:26 EST (History)
4 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:53:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2010-03-26 09:28:03 EDT
The alert subsystem will support let users provide their own "alert plugin" which can be called when an alert is fired. The "alert plugin" can then notify any arbitrary system passing on information about the alert and the resource it was triggered on.

Original, and now outdated  (introductory goals are still valid though), design wiki
http://www.rhq-project.org/display/RHQ/Design+-+pluggable+alert+senders
Comment 1 Joseph Marques 2010-04-23 13:03:13 EDT
feature testing:

1) test resource-level notifications

* create new alert definition
* add notifications
** multiple subject notifications
** multiple role notifications
** multiple direct email notifications
** add an snmp notification
** add an operation execution

* trigger a condition in the system which makes the alert fire
* check the audit trail for the alert to see that all notifications were sent and that the operation was executed

2) test resource group-level notifications

* create new compatible group
* add at least one resource member to it
* create a new group alert definition
* add all of the same notifications as were added in test #1, trigger the alert, confirm that all notifications were sent and that the operation was executed on all resource group members

3) test resource type-level notifications 

* create new alert template
* add all of the same notifications as were added in test #1, trigger the alert, confirm that all notifications were sent and that the operation was executed on all resources in the system of the given resource type the alert template was created on

upgrade testing:

* setup scenarios #1, #2, #3
* perform a full upgrade, keeping existing data
* confirm that all notifications were successfully sent and that the operation was executed in all scenarios, just as was done for the primary feature testing
Comment 2 Joseph Marques 2010-04-26 11:16:59 EDT
10:34:36) ccrouch: joseph: can you add some failure test cases too, e.g. one of each type of notification fails, but the others pass, notification failure for one member of a group

* If you want a user notification to fail, then use a bogus email address in the preferences page for that user.
* If you want a role notification to fail, then use a bogus email address for any user in that role
* If you want a direct email notification to fail, then use a bogus email address
* If you want the SNMP trap receiver to fail, then use a bogus host, port, or OID
* For operations, there are various levels of failure:

1a) For "This Resource" do not select the operation name  - should fail during execution due to no operation selected
1b) For "This Resource" select an operation with arguments, but do not enter any arguments - should fail during execution due to missing arguments
2a) For "Other Resource" do not fill in the resourceId field - should fail during execution due to no resource being selected
2b) For "Other Resource" enter the resourceId, but do not select the operation name - should fail during execution due to no operation selected
2c) For "Other Resource" enter the resourceId, select an operation with arguments, but do not enter any arguments - should fail due to missing arguments
3a) For "Relative Resource" do not select anything from any drop-downs - during execution should fail due to no resource being selected
3b) For "Relative Resource" select "Begin Search From", but do not select the operation name - should fail during execution due to no operation selected
3c) For "Relative Resource" select "Begin Search From", select an operation with arguments, but do not enter any arguments - should fail during execution due to missing arguments
3d) For "Relative Resource" select "Begin Search From" as well as "Then Filter By", but do not select the operation name - should fail during execution due to no operation selected
3e) For "Relative Resource" select "Begin Search From" as well as "Then Filter By", select an operation with arguments, but do not enter any arguments - should fail during execution due to missing arguments
3f) For "Relative Resource" select "Begin Search From" as well as "Then Filter By", select an operation without arguments, and enter "ABCDEFGHIJKL" in the name field - should fail during execution due to 0 matching resources
3g) For "Relative Resource" select "Begin Search From", then choose some option from "Then Filter By" where multiple results will be found, but leave the optional name blank -- should fail during execution because multiple resources match

(10:36:03) ccrouch: also testcases which check on the passing of information on the alert/resource into the notification

For operations, you can pass information from the alert context through the operation's arguments.  Here is information on the design for passing information through:

http://rhq-project.org/display/RHQ/Design-Resource+operations+for+alerts#Design-Resourceoperationsforalerts-Tokensandparameters

And here is an exhaustive list of individual tokens that you can pass through as operation arguments:

http://rhq-project.org/display/RHQ/Design-Resource+operations+for+alerts#Design-Resourceoperationsforalerts-Tokensforalertoperationssender

I would suggest trying all of them, and seeing which if any fail to be dynamically resolved at the time the alert triggers.
Comment 4 Sudhir D 2010-06-10 07:51:55 EDT
Feature has been verified and testcases are present for the same. Any bug related to the feature will be tracked separately. Marking this feature tracker bug as verified.
Comment 5 Corey Welton 2010-08-12 12:53:44 EDT
Mass-closure of verified bugs against JON.

Note You need to log in before you can comment on or make changes to this bug.