Bug 577217 (jon24-alert-notify) - Support for pluggable alert notifications
Summary: Support for pluggable alert notifications
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: jon24-alert-notify
Product: RHQ Project
Classification: Other
Component: No Component
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Joseph Marques
QA Contact: Sudhir D
URL:
Whiteboard:
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
TreeView+ depends on / blocked
 
Reported: 2010-03-26 13:28 UTC by Charles Crouch
Modified: 2015-02-01 23:26 UTC (History)
4 users (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-12 16:53:44 UTC
Embargoed:


Attachments (Terms of Use)

Description Charles Crouch 2010-03-26 13:28:03 UTC
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 17:03:13 UTC
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 15:16:59 UTC
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 11:51:55 UTC
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 16:53:44 UTC
Mass-closure of verified bugs against JON.


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