nodeCategoryChanged event on already-down node makes extra nodeDown events

Description

Steps to reproduce:

  1. Create a requisition with a single, reachable node in it and synchronize

  2. Wait for the node to be polled once successfully

  3. Remove the polled node from the network so that it enters a node-level outage

    1. A single nodeDown event is created when the outage is opened

  4. Add a category to the node in the requisition

  5. With the node still down, synchronize the requisition

Expected result: A single nodeCategoryMembershipChanged event is created for the node
Actual result: In addition to the expected category-related event, a handful of spurious nodeDown events follow a short time later

Acceptance / Success Criteria

None

Attachments

2

Lucidchart Diagrams

Activity

Show:

Jesse White July 1, 2015 at 10:41 AM

When receiving a nodeCategoryMembershipChanged event, the poller currently unscheduled and rescheduled all of the affected services, even if the associated packages do not change as a result of the new category. When the services for a given node are unscheduled, the relevant outages are cleared.

This behavior is fixed by only scheduling and un-scheduling and the new/removed services, keeping the others untouched.

Fixed in foundation with 617b5d4e0662a0285fbbe0fa102d72b4ae148a52.

Jeff Gehlbach June 25, 2015 at 4:49 PM

Full debug logs and DB dump from a 17.0.0-snapshot 20150617 RPM install illustrating the problem

Fixed

Details

Assignee

Reporter

Components

Priority

PagerDuty

Created June 25, 2015 at 4:42 PM
Updated July 1, 2015 at 10:41 AM
Resolved July 1, 2015 at 10:41 AM