-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Trivial
-
Resolution: Fixed
-
Affects Version/s: 18.0.4, 19.1.0, 20.0.1
-
Fix Version/s: 20.1.0, Meridian-2017.1.0
-
Security Level: Default (Default Security Scheme)
-
Labels:None
-
Sprint:Horizon - August 30th, Horizon - September 6th
The are 2 event definitions with alarm-data introduced by BSMD:
* uei.opennms.org/bsm/serviceProblem
* uei.opennms.org/bsm/serviceProblemResolved
On both cases, the alarm-type is defined with a value of 1 which is not technically correct.
alarm-type=1 means this is a problem with a resolution. That also means, it should be another event with alarm-type=2 that should resolve the problem in question (using a valid clear-key).
This is not the case here, because the serviceProblemResolved will UPDATE the existing serviceProblem alarm by changing the severity and other fields like the logMsg and description. So, technically, this serviceProblemResourced is not "resolving" an existing alarm because there is no alarm for this event.
That being said, both events should have alarm-type=3, due to how the alarm-data is defined for this pair of events.
