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.
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.
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.
accepting and setting to 1.2 for further discussion.
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
group alerting complete according to list of test cases in previous comment
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
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-13