upgrade from 1.8.11 to 1.10.0 breaks provisioning groups and discovery
Description
Environment
Acceptance / Success Criteria
Attachments
Lucidchart Diagrams
Activity
Benjamin Reed March 14, 2012 at 2:30 PM
Hah, yup! It was, in fact, a code bug, and non-obvious unless you look closely. That one's fixed now.
Richard Hesse March 14, 2012 at 1:44 PM
Multiple excluded ranges and discovery is indeed broken. I reported it in .
Maybe discoveryd hasn't changed in a long time, but that doesn't mean it worked properly.
Benjamin Reed March 14, 2012 at 11:37 AM
OK, the issue with your old 1.8 import files is resolved. I suspect the other GUI issues are related to the requisition code being unable to parse those import files. There are some old attributes from 1.6/1.8 model-import.xsd which were no longer implemented in the new provisioner. I've re-added the ability to parse them, although they will be ignored at runtime. The tags you had in your imports were set to the default behaviour anyways, so it shouldn't make a difference in The Real World.
As for your "exclude ranges" comments, I'm not sure how to parse them. Are you saying that you've turned Capsd off and have configured provisiond to handle newSuspect events? Otherwise, provisioning would have nothing to do with those nodes being found at startup.
As far as the xmlns="", that is a no-op and can be ignored. Discovery hasn't changed in a long time, I can't imagine how it would scan excluded ranges unless you already had old/deleted/disabled interfaces in your database and they were getting re-scanned (at that point, discovery is already bypassed, rescans are part of capsd).
Another possibility would be if you received traps from those excluded devices, since receiving a trap from an unknown host will trigger a newSuspect event just like discovery does.
Since you had a list of semi-unrelated things, I'm not sure what to do with this bug, other than resolve it and ask you to test the latest code and open a new issue if you see any more regressions once OpenNMS can read your old requisitions properly.
Ryan Bellows March 13, 2012 at 6:38 PM
ok, tgz'd them up and attached to the ticket.
Benjamin Reed March 13, 2012 at 6:28 PM
yup
If they contain sensitive information, you can ftp them to ftp.opennms.org/incoming, or email them (or scrub them, as long as they contain the same kinds of data/attributes)
Details
Assignee
Benjamin ReedBenjamin ReedReporter
Ryan BellowsRyan BellowsComponents
Fix versions
Affects versions
Priority
Critical
Details
Details
Assignee
Reporter
Components
Fix versions
Affects versions
Priority
CriticalPagerDuty
PagerDuty Incident
PagerDuty
PagerDuty Incident
PagerDuty
After upgrading from 1.8.11 -> 1.10.0, provisioning and discovery are broken or otherwise functioning in an incorrect manner.
Provisioning groups:
Previously-configured manual provisioning groups are present in the GUI ( admin -> Manage Provisioning Requisitions ), but no longer have nodes defined or in the database. Also reported as to have been never modified or synchronized.
When you click on edit for any of the provisioning groups the GUI throws an error.
The xml config files are still present, with the correct information, in $OPENNMS_HOME/etc/imports
Trying to add a new provisioning group ( admin -> Manage Provisioning Requisitions -> Add New Group ) creates the new group without error, but then clicking on edit -> add node throws the GUI error.
Discovery:
Immediately after upgrade, discovery no longer obeyed exclude ranges (all previously excluded ranges picked up on initial restart and provisioned).
Deleted the bogus nodes, saved and restarted discovery, and then discovery seemed to obey the exclude ranges. The only difference I could see was that discovery.xml had slightly different entries:
(from a diff)
<exclude-range>
<begin xmlns="">10.0.0.147</begin>
<end xmlns="">10.0.0.147</end>
+ <begin>10.0.0.147</begin>
+ <end>10.0.0.147</end>
</exclude-range>
Just repeat that for every exclude range.
Discovery picked up all nodes defined in the above-mentioned manual provisioning groups, behavior in 1.8.11 was that it would ignore nodes specified there.
Attached is a part of the jetty.log where the web UI threw an error when trying to edit any provisioning group.