Status: Resolved (View Workflow)
Affects Version/s: 18.0.2
Component/s: Provisioning / Discovery / Importer
Security Level: Default (Default Security Scheme)
Sprint:Horizon - Nov 2nd, Horizon - Nov 9th, Horizon - Nov 16th, Horizon - Nov 23rd, Horizon - Nov 30th, Horizon - Dec 7th, Horizon - Dec 14th
On older versions, Provisiond used to behave like Capsd when handling newSuspect events, in other words, the nodes will be created without foreignSource/foreignId.
This provides the following benefits:
- The ability to uniquely identify which nodes are part of a requisition and which don't.
- Update the nodelabel when the DNS record is changed.
- Control the inventory based on IP ranges and avoid duplicates.
Starting with 18, I figured that now the auto-discovered nodes will always be part of a requisition, if a requisition is not specified. This requisition will be called "default".
The rules for maintaining this requisition is use the IP address of the new suspect for the node-label (which is not consistent with how the node is added to the database), and use the nodeId (the primary key of the node table) for the foreignId.
Having this in mind, If the auto-discover nodes are now part of a requisition, the nodelabel is updated the very first time, but the requisition is not updated. As mentioned, the IP is used for the node label which is not consistent with the database (because it has the actual DNS name for the nodelabel). The consequence is, if this requisition is updated and synchronized, the labels will be gone, and you'll have IP addresses for the node labels, and there is no way to fix this easily.
Also, if the DNS changes the label, they won't be updated on the nodes or the requisition, because whatever exist on the requisition will prevail (i.e., it has more priority than the real DNS name of the node, even if this is a feature used by several customers).
Now, if you add a requisition policy to avoid store the discovered IPs, or the IP range for the auto-discover covers a variety of IPs of the same node, you're going to have duplicates. The reason for this is that the de-duplication is based on IP, instead of nodelabel. In my opinion, the nodelabel is less volatile than the IP. For this reason, we should provide a way to use that as the foreignId, or fix the node label problem described before, and avoid adding a new node if the label is the same. That way, we can avoid some duplicates. Of course, names can change as well, but I think it is more expected to have duplicates here, than duplicates because nodes with multiple IP addresses.
This is a problem for customers that rely on auto discovery, and also customers who want to upgrade to a newer version of opennms, considering that there is no upgrade task to update the DB, and generate this special requisition.
Here are the possibilities:
1) Revert the change, and keep the behavior that has been working for years.
2) Make sure that the generated requisitions are consistent with the content of the database when the node are created (because of the node label), and make sure that the nodes added through auto-discover will have the ability to update their labels if the DNS record is changed. Of course, we should provide an upgrade task to migrate existing installations with auto-discovered nodes.
I'll provide a step-by-step procedure to expose the problems soon.