Status: Resolved (View Workflow)
Affects Version/s: 21.1.0, Meridian-2017.1.7
Component/s: Polling / Monitors / Outages
Security Level: Default (Default Security Scheme)
Sprint:Horizon 2019 - September 4th
I've been dealing with multiple provisioning related limitations with several customers for a long time.
We can divide the major use cases into 2:
a) Customers that don't care about the discovered IP interfaces, so we can define a single policy to avoid persist them, and simplify the load on the poller.
b) Customers that require about having the discovered IPs on the database, but only monitor the ones that are explicitly declared on the requisition (monitor with the poller, for availability purposes).
One thing that the customers have in common is that the requisitions are managed externally through the ReST API, meaning they always know the content (based on their CMDB or the source they use to build the requisitions).
For [b], if the requisition only contain a single IP per node marked as primary (i.e. snmp-primary="P"), we can easily configure the poller to exclude non-primary interfaces.
Now, when the requisition has nodes with more than one interface, and keeping in mind that it is mandatory to persist the discovered interfaces but only poll the IPs declared on the requisitions, we cannot use filter at poller package level.
We can't used because the default for the snmp-primary flag is "N" when the IP is unreachable, and "S" when the IP is reachable.
That forces customers to maintain a huge amount of provisioning policies (or hard to maintain policies) to fulfill this need.
I found that you can create a poller package and pass an external list of IPs to let the poller know which interfaces to consider for polling (in terms of availability/outages); for example:
Unfortunately, even if the poller configuration is reloadable, the list of IPs is kept on a cache, and the reload process doesn't include rebuild this cache forcing you to restart OpenNMS every time the list is modified, which is not an optimal solution.
As Provisiond is an expensive process, minimizing the amount of policies is crucial to avoid unwanted side effects, and we have use cases when it is mandatory to re-import the requisitions multiple times per day.
For this reason, if we are able to rebuild all these internal caches associated with the poller configuration while reloading poller-configuration.xml, these customers can use the include-url solution and put the updated list of IPs on an external file every time they update the requisition, meaning that we gain huge performance improvements not only for provisioning but also for the poller.