Fixed
Details
Details
Assignee
Unassigned
UnassignedReporter
Jonathan Heard
Jonathan HeardLabels
Components
Fix versions
Priority
PagerDuty
PagerDuty
Created July 5, 2017 at 12:17 PM
Updated November 14, 2017 at 8:53 AM
Resolved November 14, 2017 at 8:53 AM
Upon configuring the DNS Provisioner to regularly update my requisitions from DNS, I noticed that every time the requisition was updated, at least 10 generic nodeUpdated events were generated for every host.
The log for provisiond showed that for every node in the requisition (i.e. including existing nodes) it was initiating a scan, despite having 'org.opennms.provisiond.scheduleRescanForUpdatedNodes=false' set in opennms.properties, and the attribute rescan-existing="false" set against each requisition-def in provisiond.conf:
2017-07-03 10:05:17,924 INFO [importExecutor-7] o.o.n.p.s.CoreImportActivities: Running scan phase of UPDATE: Node: 12: x.y.z, the parameter importRescanExisting was set to null during import.
When nodes are imported using DNS (and presumably the VMWare provisioner) the Provisioner.importModelFromResource sets up a Lifecycle for scanning imports, and sets the rescanExisting attribute, however the implementation of that Lifecycle in CoreImportActivitire.scanNodes is missing that attribute/parameter from its signature and therefore for all importNodes nested lifecycles it creates, rescanExisting is null, which defaults to the behaviour of true.
A second problem in my opinion is that the model for <requisition-def> ignores the global preference in opennms.properties and RequisitionDef.getRescanExisting() returns "true" if the xml-attribute wasn't specified. This should return the value of org.opennms.provisiond.scheduleRescanForUpdatedNodes if it is set.
I'm working on a patch for this - should be able to submit a suggested fix very soon.