Bug 535339 (RHQ-2045)

Summary: Allow to execute an arbitrary resource action when an alert fires
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: AlertsAssignee: Heiko W. Rupp <hrupp>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: unspecifiedCC: jginzburg, jmarques, jpviragine, sdharane, wpernath
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2045
Whiteboard:
Fixed In Version: 2.4 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-12 16:54:52 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: 534869    

Description Heiko W. Rupp 2009-04-30 15:37:00 UTC
It should be possible to e.g. restart a JBossAS when its Vm metrics show bad conditions.

See http://support.rhq-project.org/display/RHQ/Design+-+Extending+Alert+Operations for a discussion about this 

Comment 1 Joseph Marques 2009-04-30 15:46:20 UTC
here's an initial design doc -- http://support.rhq-project.org/display/RHQ/Design+-+Extending+Alert+Operations

Comment 2 Joseph Marques 2009-04-30 15:50:43 UTC
questions i would like to see answered:

* are we shooting for single or multiple operations executed as the result of an alert
** if multiple, are they ordered or unordered
*** if ordered, do we support halt on failure
* what contextual information will we make available to operation as arguments - just static info (declared at the time the alert def is created), or dynamic info (the details found instead the alert itself)

also, it might be a good idea to do circularity checking, to make sure users don't inadvertently create an alert definition which executes an operation that happens to trigger an alert which executes an operation...that eventually makes it way back around to the original alert definition.

Comment 3 Red Hat Bugzilla 2009-11-10 20:56:38 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2045


Comment 4 Heiko W. Rupp 2010-02-23 16:07:36 UTC
This will be the new alert-operations sender.

Comment 5 Sudhir D 2010-05-18 08:33:37 UTC
This can be achieved now, by script execution for a relative resource type. 

1.Browse through to the JBoss AS Server
2.Create a new alert definition with condition when JVM Free mem reaches critical value.
3.Click on Edit for the Alert Notification.
4.On the Alert notification page, click on Add New. Select the Alert sender
type as Resource Operations.
5.Select the resource selection mode as Relative Resource. 
6.Click Save
7.Select Start search from as "JBoss AS Server"
8.Click Save.
9.Select Then Filter by as "Script"
10.Provide the restart script name. (Ensure that this script is under ~/jbossas/bin directory.
11.Select operation name as "Execute Script"
12.Click Save.

Comment 6 Sudhir D 2010-05-18 08:49:47 UTC
The other way to do this is,
1.Browse through to the JBoss AS Server
2.Create a new alert definition with condition when JVM Free mem reaches
critical value.
3.Click on Edit for the Alert Notification.
4.On the Alert notification page, click on Add New. Select the Alert sender
type as Resource Operations.
5.Select the resource selection mode as This Resource
6.Select Operation name "Restart".
7.Click Save.

Comment 7 Corey Welton 2010-08-12 16:54:52 UTC
Mass-closure of verified bugs against JON.