Bug 585849
Summary: | Alert Notification: Then filter by script with script name optional | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Sudhir D <sdharane> |
Component: | Documentation | Assignee: | Deon Ballard <dlackey> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 3.0.0 | CC: | ccrouch, mfoley |
Target Milestone: | --- | Keywords: | Documentation |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-16 01:39:30 UTC | Type: | --- |
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: | |||
Bug Blocks: | 577217 |
Description
Sudhir D
2010-04-26 08:54:54 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. 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: 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. Changing modified bugs to ON_QA. Removed "then." It should be updated soon. |