Bug 534621 - (RHQ-13) Add support for group alerts
Add support for group alerts
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Alerts (Show other bugs)
1.0.1
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
Jeff Weiss
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On: RHQ-2319 RHQ-2322 RHQ-2323 RHQ-2324 RHQ-2342 RHQ-2361 RHQ-2406
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-28 19:14 EST by Charles Crouch
Modified: 2015-02-01 18:24 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.3
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 2008-02-28 19:14:00 EST
We should be extending our current group concepts to support creating alerts rather than having templates bolted on to fixed groups: i.e. all resources of a particular type. With DynaGroups its trivial to create a group representing all the resources of a given type (No more need to page through selecting lots pf resources). 

This approach will also allow people to make more fine grained use of templates, e.g. all Jboss instances starting with PROD need this template, those starting with QA need this other template.

There are definitely some non-trivial aspects to the implementation, e.g. handling nicely the case of resources which get added to the inventory, and hence group, after the alert is created but I think it makes our template implementation cleaner and more powerful. 
Comment 1 Charles Crouch 2008-02-28 20:02:20 EST
Talking this through with Joe its obvious we still need to keep the metric templates since we need a place to update the default settings which are shipped with each plugin. However given we dont ship any alert templates there is nothing there which could be edited by a user, so I think creating alert templates through groups might be more intuitive as we increase the set of things you can do on a groups.
Comment 2 Greg Hinkle 2008-04-02 11:33:54 EDT
I don't think requiring the creation of groups to do this is more intuitive. I'd be fine with having that as an additional feature, but i think the current templates should stay. In fact, I'd like to see a way created so that plugins could define default alert templates.
Comment 3 Joseph Marques 2008-07-21 01:26:42 EDT
accepting and setting to 1.2 for further discussion.
Comment 4 Joseph Marques 2009-08-06 06:27:06 EDT
list of features and system side-effects included under the "group alerting" umbrella:

basics

1a -- if the resource group is a compatible group, then allow the creation of alert definitions at the group level
1b -- support alert>definitions sub-tab at the resource group level, which supports CRUD operations for group alert definitions
1c -- support alert>history sub-tab at the resource group level, which supports viewing as well as deleting alerts that have been created against any resource that is currently in the group
1d -- support searching alerts at the group level by alert priority and creation date
1e -- support sorting and paging for 1b and 1c

parity with alert templates

2a -- similar to alert templates...updates to a group alert definition should trickle down to the corresponding resource-level alert definitions: any and all general properties; the set of conditions; and the notification, dampening, and recovery rules (see 2d)
2b -- similar to alert templates...when a group alert definition is created, a copy of the alert definition is applied to each member of the group
2c -- similar to alert templates...when a group alert definition is deleted, its corresponding children alert definitions should be deleted too
2d -- similar to alert templates...when a group alert definition is updated, the updates should trickle down to its corresponding children alert definition (see 2a)
2e -- similar to alert templates...an alert definition spawned from a group alert definition can be deleted, but if the group alert definition is updated it will be recreated with the new group alert definition data
2f -- similar to alert templates...an alert definition spawned from a group alert definition can be updated, but if the group alert definition is updated the resource-level changes will be overridden
2g -- similar to alert templates...an alert definition spawned from a group alert definition can be updated and "frozen", then if the group alert definition is update those updates will NOT trickle down to this alert definition
2h -- similar to alert templates...an alert definition spawned from a group alert definition can be updated and "frozen", but if the group alert definition is deleted it will still delete this "frozen" resource-level alert definition

side-effects of resource group maintenance

3a -- if a compatible group has a member added to it that makes it a mixed group, all group alert definitions must be removed (see 3a)
3b -- if a new member is added to a resource group, all group alert definitions need to be applied to create corresponding alert definition on that resource
3c -- if an existing member is removed from a resource group, all resource-level alert definitions spawned as part of group definitions need to be removed from that resource
3d -- if a resource group is deleted, then all group alert definitions for that group must be deleted to, which implies that all corresponding resource-level alert definitions spawned from them need to be deleted too (see 3a)

user interface

4a - 'flag' icon for compatible groups on browse resources
4b - 'flag' icon for compatible groups on inventory>overview sub-tab of a resource (groups this resource is a member of)
4c - alert tab when viewing group details
4d - right-click 'flag' icon when in the group left-nav tree

additional testing activities

* since this feature adds a few new columns to the alerting tables, there needs to be testing to make sure that db-upgrade (and fresh installs) work against our support databases. * need to make sure we haven't regressed on alert templates or resource-level alert definitions 
Comment 5 Joseph Marques 2009-08-06 08:15:11 EDT
group alerting complete according to list of test cases in previous comment
Comment 6 Jeff Weiss 2009-08-12 15:01:35 EDT
Tested via testopia testplan
https://testopia.devel.redhat.com/bugzilla/tr_show_plan.cgi?plan_id=1120

All tests have been run, issues have been opened separately.  rev4856
Comment 7 Red Hat Bugzilla 2009-11-10 15:32:12 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-13

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