Extending Alerts to Execute Operations on any resource in RHQ
Alerts are required to be extended so that operations are executed on any resource in the system. This document explains two approaches to reach that functionality.
Current Model
The current model allows an operation to be scheduled on the same resource when an alert is fired. However we would like to extend this model to allow multiple operations to be executed on any resource in the inventory.
Supporting Multiple Operations
When an alert is fired, one or more operations on different resources can get executed. This leads to the definition of a stack where operations triggered by an alert are defined. In that context every alert definition contains a stack of operations that are executed on different resources.
Operations Execution
The stack of operations can be executed in two different ways:
Simultaneous Execution
When operations are selected to be executed simultaneously then all operations are executed in a random order irrespectively of their order in the stack. Each operation can be thought of as a different thread executing after the alert is fired.
Ordered Execution
When operations are selected to be executed in order then each operation is waiting on it predecessor to execute before it is actually fired. All the operations are executed sequentially by the order in which they appear in the stack.
Halt on Failure
The halt on failure flag indicates that the execution of the stack should be aborted when an operation fails. Please note that the halt on failure is applicable only when the mode of operation is set to Ordered Execution.
Design Update
The concept implies a change in the model that would allow linking alert definitions to operation definitions (1 to many relationship) and linking alerts to operations histories. The following diagram illustrates the concept:
Changes to alert templates
The changes incurred in this design-document do not propagate to Alert Templates. Alert Templates are kept unchanged, meaning that at this point in time users will not be able to schedule operation execution when defining / update an alert template.
Distinguishing different operations.
To be able to distinguish between operations fired on different resources, a mouse over event will be added to the rows so that a caption shows the full hierarchy of the resource in question. The same concept can be illustrated as well through a dialog box containing the full hierarchy.
UI Changes
The UI pages need to be updated as follows. Please note that this is a prototype format and not the final decorated forms and views.
This is a snapshot of creating the Operations Definitions from within the Alerts. This page is linked from the Alert Edit page.
This page lists the operations and allows them to be re-ordered. Note that the execution depends on the order of the operations, thus the move up / move down functionality is used for that purpose. The full final interface will contain as well the move to top / move to bottom links and will include full pagination and sorting on the columns.
The following page is a search page where Operations Definitions associated with an Alert Definition can be searched.
This last snapshot page is a search page where history of operations is searched.
Passing the Alert Info as an Argument to an Operation
One additional feature that is Operations that are created by an alert have the alert object embedded in the operation, this will expose the alert and alert definition to the operation.
The alert is passed on to the operation through the following mechanism:
The operation is checked to see if it was triggered by an operation, if that condition is satisfied, then the alert object is always passed as a parameter within the configuration object, the OperationInvocation invoked by the OperationManagerBean transmits the data to the PluginContainer which in return exposes the alert to the required plugin.