Bug 585849 - Alert Notification: Then filter by script with script name optional
Summary: Alert Notification: Then filter by script with script name optional
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Documentation
Version: 3.0.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Deon Ballard
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks: jon24-alert-notify
TreeView+ depends on / blocked
 
Reported: 2010-04-26 08:54 UTC by Sudhir D
Modified: 2011-06-16 01:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-16 01:39:30 UTC
Embargoed:


Attachments (Terms of Use)

Description Sudhir D 2010-04-26 08:54:54 UTC
Description of problem:
The script name for the type script for Then Filter by in alert notification action page is optional. It leaves in ambiguity as to which script will run when the alert condition is met.

Version-Release number of selected component (if applicable):

How reproducible:
100%

Steps to Reproduce:
1.Resource Alert Definition -> Notification Actions
2. Click on Add New button 
* for "Alert Notification Name:" type in anything
* for "Alert Sender Type:" select "Resource Operations"
* click "OK"
< that new notification should be automatically selected in the table>
< the "Configuration Details" panel should appear at the bottom of the screen
* for "Resource Selection Mode:" choose "Relative Resource"
* click "Save"
* for "Start Search From:" choose "JBossAS Server"
* for "Then Filter By:" choose "Script" 
Script name here is optional.

  
Actual results:
The script name is optional and when the Notification action is saved, the scritp will save and there is ambiguity as to which script will run when the alert condition is met.

Expected results:
The script name should not be optional and when script is entered, there should be some validation to check if the script exist in the expected location.

Additional info:

Comment 1 Joseph Marques 2010-04-26 14:09:09 UTC
Not sure if this is a bug.  

One of the valid use cases is that you want to execute an operation on a resource which is your ancestor.  In this case, you would choose the "start search from" and leave the rest of the form empty.

Another valid use case is that you want to execute an operation on a resource which is known to be a logical singleton.  If you know there is only ever going to be a single instance of a particular resource type, then you might want to leave the name field empty.

Comment 2 Charles Crouch 2010-04-26 16:14:03 UTC
All the comments here are reasonable. I don't think we want to make the name box required for the usecases Joseph outlines, but I think it would be useful to provide a *brief* description of what our execution strategy is if the search criteria returned 0 or >=2 resources.

I think we also, if we're not doing so already, need to indicate in the alert history if the search criteria returned 0 or >=2 resources, as this is not expected/desired and is something people are going to want to know about I think. If we don't do anything on the alert history side we should atleast log a WARN into the server log

Comment 3 Joseph Marques 2010-04-26 16:24:10 UTC
(In reply to comment #2)
> All the comments here are reasonable. I don't think we want to make the name
> box required for the usecases Joseph outlines, but I think it would be useful
> to provide a *brief* description of what our execution strategy is if the
> search criteria returned 0 or >=2 resources.

FYI, there's nothing that actually requires exactly one match to be the only success case.  If we find multiple resources, we could handle that case by simply executing the operation on all resources it matched, passing the same arguments through to each.  

Also, if it matched 0 resource, it may not be an explicit failure - if you apply an alert template to many resources some of those resources may have the resource in question while others don't, but it was simplest from a user perspective to add the rule once at the template level.  At most, we should provide an informative audit trail, but not halt notification processing.

Comment 4 Corey Welton 2010-12-16 13:22:19 UTC
Deon, can we doc this? Ping joseph for appropriate text.

Comment 5 Deon Ballard 2010-12-20 15:57:09 UTC
I added a note to the alert script section:

http://documentation-stage.bne.redhat.com/docs/en-US/JBoss_Operations_Network/2.4/html/Basic_Admin_Guide/assigning-alert-scripts.html

And a similar note to the alert operations section:

http://documentation-stage.bne.redhat.com/docs/en-US/JBoss_Operations_Network/2.4/html/Basic_Admin_Guide/assigning-alert-operations.html#setting-alert-ops

If the note is clear enough, then I'll update the public docs.

Comment 6 Deon Ballard 2011-05-19 18:27:56 UTC
Changing modified bugs to ON_QA.

Comment 8 Deon Ballard 2011-05-20 19:41:25 UTC
Removed "then." It should be updated soon.


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