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

The %dpname% breaks the alarm life-cycle when having multiple minions per location



    • Bug
    • Status: Resolved (View Workflow)
    • Critical
    • Resolution: Fixed
    • Meridian-2019.1.17, Meridian-2020.1.6, 27.1.0
    • 28.0.0
    • Alarms
    • Security Level: Default (Default Security Scheme)
    • Horizon 2021 - Mar 17 - Mar 31, Horizon 2021 - Mar 31 - Apr 14


      When using Minions, it is common to have more than one per location to guarantee that requests to a given location will always be processed, even if one Minion fails, or to split load when processing lots of Syslog messages Traps, or Flows.

      Historically, a placeholder called %dpname% is part of the reduction-key and clear-key for all the event definitions with alarm-data.

      When there are Minions involved, that placeholder is replaced at runtime with the Minion ID, which can lead to problems with the alarm life cycle, breaking the logic to decide whether or not an alarm should be cleared.

      For instance, one Minion can receive a trigger event, and its sibling can receive the corresponding rearm event. Then, the alarms generated will have different content for the %dpname%, and because of that, there is no way that the trigger event will be cleared because the clear-key of the rearm event will never match the reduction-key of the trigger event.

      A solution could be removing that placeholder from all the event definitions with alarm-data, but that will make upgrades complicated, as essentially all the event definition files will appear as changed.

      Also, there might be scenarios when having %dpname% makes sense.

      For this reason, I believe it would be useful to have a flag to ignore the %dpname%, so for the users that are affected due to the broken alarm life-cycle can use OpenNMS the way it works when Minions are not involved while keeping compatibility with the current behavior, in case, there is a justification for it.




            cpape Christian Pape
            agalue Alejandro Galue
            0 Vote for this issue
            4 Start watching this issue