This is an old revision of the document!
ipdevpoll is the planned replacement for getDeviceData, becoming the third generation SNMP polling framework for NAV. This page will lay out the various design ideas and specifications for the new program.
The gDD core application has the following basic tasks:
Scheduling of jobs instead of individual plugins has been chosen to simplify the application due to the high level of dependency between some of the plugins. Each job defined in the the gDD configuration defines a set of plugins that are to be run at a given interval. The scheduling of these intervals is handled using Twisted's built in scheduling mechanisms.
The previous version of gDD determined plugin execution order based on numeric values assigned to each plugin, this implies that every plugin must know about the value of all other plugins to be sure that it gets executed before and/or after relevant plugins. To avoid this error prone method of ordering using a simple dependence system between plugins has been suggested. Each plugin needs to know which plugins need to run before itself. This data can be used to do a topological sort based on the dependence arcs between plugins.
data persistence/containers
There are two main groupings of plugins that need to be considered, inventory plugins and logging plugins. These two groups should by default be configured to run as separate jobs as their scheduling intervals vary greatly.
Installed plugins should be specified as a simple list of module names to import in string form (much like django's INSTALLED_APPS setting). During import each plugin will be responsible for registering itself by calling gdd.plugins.register(<class>), this will add the plugin to a global list of plugins which will be topologically sorted once the plugin list has been processed.
Each plugin will be called in order and must itself determine if the netbox in question is of instrest (ie. dues it support the mibs that the plugin knows about, does the netbox vendor match those supported by the plugin…). Once this is decided the plugin can either pass or start collecting more SNMP data and populate the data persistence store and/or modify the allready there (ie. vendor specific interpretations). Once all plugins have run gDD must ensure that the updated data is stored to the database.
To keep the plugin directory somewhat organized the following organization has been proposed:
/plugins /inventory - entity_mib.py - ... /cisco - entity_mib.py - ... /hp - .. /log - arp.py - ...
The mercurial repositories can be found at