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:
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.