The reason it's holding up my upgrade, is because I want to move to provisioning everything using directed discovery - and if that's going to work the way we require it in our environment, we need to be able to use some policy rules in the foreign source definitions to not persist interfaces with hostnames that match a particular regex.
The match key for "org.opennms.netmgt.provision.persist.policies.MatchingIpInterfacePolicy" seems to use the iphostname field when matching with "hostName", and so name matches always fail. So it's not that it breaks a *lot* of stuff, but rather it stops us using it in the way we need to - and rather than switch now and fix/change the node data later, we would rather start off on the correct footing :) It's not an in-place upgrade we doing, but a new installation with new design goals. The new provisioning is great by the way, during testing I added ~1500 nodes, fully scanned in about 15 mins! Really great work :) (P.S. I'm not just trying to butter you to get the bug fixed any quicker - that's meant to be genuine!) Cheers, Just -- View this message in context: http://opennms.530661.n2.nabble.com/provisioning-iphostname-tp7580867p7580924.html Sent from the OpenNMS - devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
