While designing ipdevpoll, we decided to throw out the over-engineered OID database from NAV. The tables haven't been removed yet, but none of the new code makes use of them.
Now, it looks like we need to keep some aspects of the OID database.
While configuring Cricket, makecricketconfig needs to know ahead of time which proprietary OIDs from the Cricket config files are supported by an IP device. In other words, makecricketconfig still needs to have an SNMP OID profile for a box.
John-Magne has written a script that will pull all configured OID labels from the Cricket configuration tree, and insert them into NAV's snmpoid table. I've written an oidprofiler plugin to ipdevpoll, which does most of what getDeviceData's OID tester did.
But, some superfluous fields can be removed from the snmpoid and netboxsnmpoid tables to complete the transition to NAV 3.6:
* The netboxsnmpoid.frequency and snmpoid.defaultfreq fields are right out, since these tables will no longer be used for scheduling anything.
* snmpoid.oidsource is irrelevant in the new context.
* snmpoid.descr, oidname and mib can be safely removed. If anyone needs them, they can be inferred by a mib compiler.
* snmpoid.decodehex is just ridiculous.
* snmpoid.match_regex is unnecessary, because there is no such information in the Cricket config files.
And the more interesting part:
* snmpoid.uptodate - We can't really assess whether an snmpoid is really up-to-date or not. When gDD sees an snmpoid with uptodate=false, it will query that snmpoid for all netboxes and set uptodate=true. But "all netboxes" only means all netboxes that are online at the moment. There is no guarantee that all netboxes were actually queried.
My suggestion is that we rather set netbox.uptodate=false for all netboxes when snmpoids are inserted or updated. Re-profiling a netbox is not a huge operation (especially since the current cricket config contains about 12 OIDs that need to be profiles), and new snmpoids will not be inserted very often.
This can be implemented via a simple trigger or rule on the snmpoid table.
This is FYI, and a heads-up for a possible discussion on Monday's status meeting.