Red Hat Bugzilla – Bug 585849
Alert Notification: Then filter by script with script name optional
Last modified: 2011-06-15 21:39:30 EDT
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):
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.
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.
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.
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.
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
(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.
Deon, can we doc this? Ping joseph for appropriate text.
I added a note to the alert script section:
And a similar note to the alert operations section:
If the note is clear enough, then I'll update the public docs.
Changing modified bugs to ON_QA.
Removed "then." It should be updated soon.