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

Cleared alarms with closed ticket state not removed when using a hybrid approach

    XMLWordPrintable

    Details

    • Sprint:
      Horizon 2021 - Apr 14 - Apr 28, Horizon 2021 - Apr 28 - May 12
    • HB Backlog Status:
      HB

      Description

      When I created NMS-13189, I described the 4 use cases I thought users would ever use.

      To recapitulate, here are the customer requirements:

      • The customer doesn't want the Tickets to be automatically created by OpenNMS. An operator will create them manually from the alarm details page.
      • The customer doesn't want the Tickets to be automatically closed for cleared alarms.
      • The customer doesn't want the Alarms to be automatically cleared for closed tickets.
      • The customer wants the ticket state to be automatically updated for cleared alarms... and have those alarms to be cleared.

      Besides what was explained on that other Jira issue, it turns out that the customer who triggered that effort wants to use the Ticketing Integration differently.

      They are interested in a hybrid approach. They want to create tickets manually from the OpenNMS WebUI via the alarm page. Still, they want Alarmd to update the ticket state automatically based on what happened in the TTicket Implementation (in their case, Remedy). Meaning, if they close the ticket, the alarm should be automatically updated. Then, the cleared alarms (with a closed ticket state) must be automatically removed from the database.

      My initial thought was to apply the following change to the "updateTickets" rule in "alarmd.drl":

      --- /var/opennms/etc-pristine/alarmd/drools-rules.d/alarmd.drl    2021-04-06 13:28:12.000000000 -0400
      +++ /opt/opennms/etc/alarmd/drools-rules.d/alarmd.drl    2021-04-12 12:41:17.664895730 -0400
      @@ -154,14 +154,12 @@
       end
      
       rule "updateTickets"
      -  enabled false
      +  enabled true
         when
           $sessionClock : SessionClock()
           $ticketer : AlarmTicketerService(isTicketingEnabled() == true)
      -    $alarm : OnmsAlarm(severity.isGreaterThan(OnmsSeverity.CLEARED) &&
      -                       (alarmType == OnmsAlarm.PROBLEM_TYPE || alarmType == OnmsAlarm.PROBLEM_WITHOUT_RESOLUTION_TYPE) &&
      -                       TTicketState != null)
      -    not( OnmsAlarm( this == $alarm ) over window:time( 15m ) )
      +    $alarm : OnmsAlarm(TTicketState != null)
      +    not( OnmsAlarm( this == $alarm ) over window:time( 1m ) )
         then
           $ticketer.updateTicket($alarm, new Date($sessionClock.getCurrentTime()));
       end
      

      That solves part of the problem; updating the alarm with the ticket state no matter what.

      However, the cleared alarms with a closed ticket state are never removed from the database, although the condition triggers either the "cleanUp" or the "fullCleanUp" rule in "alarmd.drl".

      I tested in the following two scenarios, using JIRA:

      1) Close the ticket before receiving the resolving event.

      1.1) Generate a nodeLostService
      1.2) Manually create the ticket from the alarm page in the OpenNMS WebUI
      1.3) Close the ticket on JIRA
      1.4) Wait until the alarm is updated (i.e., the ticket state should change from OPEN to CLOSED)
      1.5) Generate a nodeRegainedService
      1.6) Verify that the trigger alarm is now cleared (and the ticket state remains as CLOSED)
      1.7) Wait until the alarm is removed from the database, which should happen according to the "cleanUp" rule (not happening).

      2) Close the ticket after receiving the resolving event.

      1.1) Generate a nodeLostService
      1.2) Manually create the ticket from the alarm page in the OpenNMS WebUI
      1.3) Generate a nodeRegainedService
      1.6) Verify that the trigger alarm is now cleared (and the ticket state remains OPEN)
      1.5) Close the ticket on JIRA
      1.6) Wait until the alarm is updated (i.e., the ticket state should change from OPEN to CLOSED)
      1.7) Wait until the alarm is removed from the database, which should happen according to the "cleanUp" rule (not happening).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              cgorantla Chandra Gorantla
              Reporter:
              agalue Alejandro Galue
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                HB Grooming Date:

                  Git Integration