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

rescan-exitsing attibute of requisition-def tag in provisiond-configuration.xml is not passed to scanNode() in CoreImportActivities




      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.




            Unassigned Unassigned
            jondevit Jonathan Heard (Inactive)
            0 Vote for this issue
            2 Start watching this issue