Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-9497

The alarm-type for BSM event definitions is conceptually incorrect

    Details

    • 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
    • Component/s: BSM, Eventd
    • Security Level: Default (Default Security Scheme)
    • Labels:
      None
    • Sprint:
      Horizon - August 30th, Horizon - September 6th

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              ranger Benjamin Reed
              Reporter:
              agalue Alejandro Galue
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: