NMS-17006: Write sysName to node-label in requisition to match database

[Torchtopher]

This fixes nms-17006, where a node would get assigned a name based on the value of sysName from SNMP, but this node label would not be reflected in the requisition, so a rescan would overwrite sysName with the IP and set it to user defined (line 192 of OnmsNodeRequisition.java). Now when updating the node name to sysName, it also updates the requisition.

Below is a video showing this behavior (previously node-label in the requisition xml would be set to the IP)

Video

I can change whatever, just wanted to see if overall I made the patch in the right code.

All Contributors

• [Yes] Have you read our Contribution Guidelines?
• [Yes] Have you (electronically) signed the OpenNMS Contributor Agreement?

Contribution Checklist

• Please make an issue in the OpenNMS issue tracker if there isn't one already.
  Once there is an issue, please:
  1. update the title of this PR to be in the format: ${JIRA-ISSUE-NUMBER}: subject of pull request - yes
  2. update the Jira link at the bottom of this comment to refer to the real issue number - yes
  3. prefix your commit messages with the issue number, if possible - can rewrite them
  4. once you've created this PR, please link to it in a comment in the Jira issue - ok

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-17006

[dino2gnt]

Conceptually, nothing in OpenNMS should be modifying the content of the requisition dynamically. Requisitions are not guaranteed to be local to OpenNMS or even be managed locally. They exist as a source of truth which is frequently built from an external data source and pushed to OpenNMS, which would still overwrite these local changes.

Realistically, nodelabel changes such as you're describing are a relic of the days of automated discovery as the primary means of building an OpenNMS inventory and really shouldn't touch requisitioned nodes in the first place. If the administrator wants a friendly label on the node, it should go into the requisition :)

[cgorantla]

As Dino said, if this is only relevant for auto discovered nodes. The ideal location for this workflow should beNewSuspectScan and after NodeScan.

[cgorantla]

Need updates.

[Torchtopher]

I moved that logic to NewSuspectScan and wrote a function that wraps createUpdateRequistion which already does what we want. From testing it sometimes takes a minute to get to fixing the label (so the requisitions label is "wrong" for that time). Sorry for the delay.

[cgorantla]

we should only update node label on the requisition with the new label if they differ.