Alarm Service Layer is needed for proper Alarm workflow

Description

As we are currently making many improvements to Alarm handling in OpenNMS in support of project Sextant, we should be creating a service layer and an API for managing the state of Alarms in OpenNMS.

Currently, Alarmd does emit events for a few state changes but a more granular set of events is required for external systems to be aware of changes.  Currently, there are at least 3 places where Alarm state is officially changed and should be centralized into a single process: Alarmd, Vacuumd, and Ackd.  Additionally, the alarm change notifier plugin should be removed from the distribution as part of this service layer.

The use case for this comes from a commercial support customer has requested that Events be emitted when Alarms are acknowledged and when journal entries or sticky notes are made to an Alarm.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jesse White July 6, 2018 at 1:52 PM
Edited

With the changes in  the state is centrally managed and any interested services can listen for changes to this state by implementing the AlarmEntityListener interface.

In the description we talk about a service layer, an api, granular events, the alarm change notifier plugin... it's not clear to me what the success criteria is for this enhancement.

Details

Assignee

Reporter

Components

Affects versions

Priority

PagerDuty

Created July 6, 2018 at 11:26 AM
Updated September 21, 2021 at 9:27 PM