This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:blueprints:ipdevpoll [2009/07/13 13:57] klette Updated storage information and some core specifications |
devel:blueprints:ipdevpoll [2012/05/07 11:26] (current) morten fix url |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== ipdevpoll design specification ====== | ====== ipdevpoll design specification ====== | ||
+ | |||
+ | **This page is currently being updated to match whats being developed. Dont trust this stuff just yet :-)** | ||
+ | |||
===== Introduction ===== | ===== Introduction ===== | ||
//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. | //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. | ||
Line 17: | Line 20: | ||
Jobs are a group of plug-ins run in a specified order, and scheduled at a specified time interval. The scheduling is handled by Twisted. | Jobs are a group of plug-ins run in a specified order, and scheduled at a specified time interval. The scheduling is handled by Twisted. | ||
- | NAV provide two jobs in the default configuration, ``Inventory`` and ``Logging``. | + | NAV provide two jobs in the default configuration, ''Inventory'' and ''Logging''. |
- | These provide a sane order for the plug-ins to run. The user may specify their own jobs and schedules in ``jobs.conf``. The configuration files used by ipdevpoll follows the syntax | + | These provide a sane order for the plug-ins to run. The user may specify their own jobs and schedules in ''jobs.conf''. The configuration files used by ipdevpoll follows the syntax |
demanded by the python ConfigParser-module. | demanded by the python ConfigParser-module. | ||
- | + | \\ | |
- | == Example jobs.conf == | + | \\ |
+ | Example jobs.conf | ||
<code ini> | <code ini> | ||
[inventory] | [inventory] | ||
Line 39: | Line 43: | ||
Data is provided through the use of shadow-classes of django-models. Plugins never write django-objects directly. This is handled by the job the plugin runs in at the end of each job. | Data is provided through the use of shadow-classes of django-models. Plugins never write django-objects directly. This is handled by the job the plugin runs in at the end of each job. | ||
- | Shadow-classes are created in ``nav.ipdevpoll.storage`` | + | Shadow-classes are created in ''nav.ipdevpoll.shadows'' |
- | + | \\ | |
- | == Example shadowclass specification == | + | Example shadowclass specification |
<code python> | <code python> | ||
class Interface(Shadow): | class Interface(Shadow): | ||
Line 48: | Line 52: | ||
</code> | </code> | ||
- | The Shadow-class has two important attributes. ``__shadowclass__`` specifies which django model to mimic. This will make any instances of the shadowclass | + | The Shadow-class has two important attributes. ''<nowiki>__shadowclass__</nowiki>'' specifies |
- | answers to the same attributes as the django model. When a property is changed on the shadowclass, the class will set it state to touched. This is needed | + | which django model to mimic. This will make any instances of the shadowclass |
- | for determining wheter to update an object or not at the end of a run. To lookup existing objects in the database the storage system first tries the primary | + | answers to the same attributes as the django model. When a property is changed |
- | key field on the object. If the PK is None, the ``__lookup__``-attribute is used for the checking. The ``__lookup__`` attribute is a list of strings and tuples. | + | on the shadowclass, the class will set it state to touched. This is needed for |
- | Tuples specifies combined lookups, while strings specifies single field lookups. The different lookups are tried in the order they are defined in the list. If we look | + | determining wheter to update an object or not at the end of a run. To lookup |
- | at the example above, it will first try to get an existing object with only the ``interface.id``-field. If its unavailable it tries the first object in the lookup-list, | + | existing objects in the database the storage system first tries the primary key |
- | a combined search for objects matching both the ``netbox`` and ``ifname`` properties on the shadow instance. If unsuccessful it goes on to the next lookup field. | + | field on the object. If the PK is None, the ''<nowiki>__lookup__</nowiki>''-attribute is used |
+ | for the checking. The ''<nowiki>__lookup__</nowiki>'' attribute is a list of strings and tuples. | ||
+ | Tuples specifies combined lookups, while strings specifies single field | ||
+ | lookups. The different lookups are tried in the order they are defined in the | ||
+ | list. If we look at the example above, it will first try to get an existing | ||
+ | object with only the ''interface.id''-field. If its unavailable it tries the | ||
+ | first object in the lookup-list, a combined search for objects matching both | ||
+ | the ''netbox'' and ''ifname'' properties on the shadow instance. If | ||
+ | unsuccessful it goes on to the next lookup field. | ||
+ | |||
+ | There are two major "gotcha"s here. First of, the lookups must be unique. If | ||
+ | multiple rows are returned an exception is raised. The second is primary key | ||
+ | lookups where the primary key is not an AutoField; if no rows are found when | ||
+ | using non-AutoField primary keys, a new object is created. If the field is an | ||
+ | AutoField however, and no rows are returned, an exception is raised. | ||
- | There are two major "gotcha"s here. First of, the lookups must be unique. If multiple rows are returned an exception is raised. The second is primary key lookups where | + | Deletion of objects in the database is done if the shadowobject has its |
- | the primary key is not an AutoField; if no rows are found when using non-AutoField primary keys, a new object is created. If the field is an AutoField however, and no | + | ''delete''-property set to True. |
- | rows are returned, an exception is raised. | + | |
- | Deletion of objects in the database is done if the shadowobject has its ``delete``-property set to True. | + | Once the job is done the storage routine is called. The storage system then parses all |
+ | the shadow objects contained in ''job_handler.container'' and make s sure all foreignkeys needed for the storing | ||
+ | an instance are saved before the object it self. | ||
==== Plugins ==== | ==== Plugins ==== | ||
Line 174: | Line 193: | ||
=== Implemented plugins === | === Implemented plugins === | ||
- | Already implemented plugins can be found on [[devel:ipdevpollplugins]] | + | Already implemented plugins can be found on [[devel:ipdevpoll:plugins]] |
===== Database changes ===== | ===== Database changes ===== | ||
Line 192: | Line 211: | ||
The IF-MIB has no concept of an interface/module relationship. Information about such a relationship will most likely come from proprietary MIBs (or possibly a properly populated ENTITY-MIB), and should be treated as a bonus if found. Ie. NAV's model should add to the interface table a mandatory foreign key to netbox, and only an optional foreign key into the module table. | The IF-MIB has no concept of an interface/module relationship. Information about such a relationship will most likely come from proprietary MIBs (or possibly a properly populated ENTITY-MIB), and should be treated as a bonus if found. Ie. NAV's model should add to the interface table a mandatory foreign key to netbox, and only an optional foreign key into the module table. | ||
- | ===== Code ===== | + | ===== Status ===== |
- | The mercurial repositories can be found at http://metanav.uninett.no/hg/features/ipdevpoll/ | + | The first NAV release to include ipdevpoll was version 3.6. |
===== References ===== | ===== References ===== |