clarencen/lshift — Issue #166: Extended Escalation Manager
Author: clarencen
Created: 2011-11-14 22:41:56+00:00
State: open

(This ticket probably depends on #294)

#272 introduced a simple first working version of the escalation
facility that allows scan to trigger a set of entity scoped actions.
This trigger fires whenever a scan is run for every entity scoped
action that is configured to escalate. The primary use case of this is
to be able to configure a scheduled scan (e.g. to run once overnight)
that will invoke a pre-defined repair action.

The scope of #272 is deliberately limited, hence this ticket addresses
the areas where the escalation manager should be made more flexible
and powerful. Here is a list of features it should have:

* The process of escalation should be polling driven, not event driven
* A series of ordered escalation steps should be configurable
* Each escalation step includes an action that could invoked. The
escalation could be an repair action or a notification. Potentially
the URL field could be misused to define an SMTP recipient.
* The state of an escalation is held persistently until a match event
for the underlying entity occurs. The final possible state of an
escalation will be the result of the last configured action. After
this step has been invoked, only a manual intervention can repair the
underlying entity.
* It should be possible to review all current escalations.
* The configuration XML needs some thought, because it is likely that
escalations will re-use repair definitions, so we will need to come up
with concise way of defining the config.