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

The alarm-type for BSM event definitions is conceptually incorrect

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Trivial
    • Resolution: Fixed
    • 18.0.4, 19.1.0, 20.0.1
    • 20.1.0, Meridian-2017.1.0
    • BSM, Eventd
    • Security Level: Default (Default Security Scheme)
    • None
    • 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

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

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.