[OpenNMS/opennms] 334c62: NMS-19979: clear data collection alarms after a re...

  Branch: refs/heads/foundation-2024
  Home:   https://github.com/OpenNMS/opennms
  Commit: 334c627d758f9be390e459993e94b790fcf4726a
      https://github.com/OpenNMS/opennms/commit/334c627d758f9be390e459993e94b790fcf4726a
  Author: Marshall Massengill <[email protected]>
  Date:   2026-08-27 (Thu, 27 Aug 2026)

  Changed paths:
    M opennms-services/src/main/java/org/opennms/netmgt/collectd/CollectableService.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/CollectableServiceTest.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/CollectdIT.java
    M opennms-services/src/test/java/org/opennms/netmgt/collectd/ThresholdIT.java

  Log Message:
  -----------
  NMS-19979: clear data collection alarms after a restart or collectd reload (#8774)

* NMS-19979: clear data collection alarms after a restart or collectd reload

A dataCollectionFailed alarm never cleared if collection recovered across an
OpenNMS restart or a collectd configuration reload.

CollectableService keeps the last collection status in memory and updateStatus()
only emits an event on a transition. That status was seeded to SUCCEEDED, and
both a restart and rebuildScheduler() discard and rebuild every
CollectableService, so the recovery was no longer a transition, no
dataCollectionSucceeded was sent, and the alarm was orphaned.

Seed it to UNKNOWN instead. The first collection then always transitions,
whichever way it goes: a success emits dataCollectionSucceeded and clears the
alarm the previous generation left behind, and a failure emits
dataCollectionFailed exactly as before. Subsequent collections are unchanged,
so this costs one extra event per collected service per restart or reload, not
one per collection cycle.

An unmatched dataCollectionSucceeded creates a Normal severity alarm of its own,
which the default alarmd cleanUp rule deletes after five minutes.

* NMS-19979: Update collectd tests for the first-collection succeeded event

Seeding m_status to UNKNOWN makes the first successful collection of every
scheduling generation a transition, so it now emits dataCollectionSucceeded.
Two existing tests assumed that event never fired.

ThresholdIT anticipates it once per generation. A nodeCategoryMembershipChanged
event unschedules and reschedules the node, building a fresh CollectableService,
so the reschedule reports success again after the second category change.

CollectdIT.testOneMatchingSpec performs real collections, so it accounts for the
send explicitly rather than loosening tearDown's verifyNoMoreInteractions.



To unsubscribe from these emails, change your notification settings at https://github.com/OpenNMS/opennms/settings/notifications


_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq
opennms-cvs mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-cvs