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 14:04] klette |
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 40: | 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 | ||
Line 49: | Line 52: | ||
</code> | </code> | ||
- | The Shadow-class has two important attributes. ''__shadowclass__'' specifies | + | The Shadow-class has two important attributes. ''<nowiki>__shadowclass__</nowiki>'' specifies |
which django model to mimic. This will make any instances of the shadowclass | which django model to mimic. This will make any instances of the shadowclass | ||
answers to the same attributes as the django model. When a property is changed | answers to the same attributes as the django model. When a property is changed | ||
Line 55: | Line 58: | ||
determining wheter to update an object or not at the end of a run. To lookup | 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 key | existing objects in the database the storage system first tries the primary key | ||
- | field on the object. If the PK is None, the ''__lookup__''-attribute is used | + | field on the object. If the PK is None, the ''<nowiki>__lookup__</nowiki>''-attribute is used |
- | for the checking. The ''__lookup__'' attribute is a list of strings and tuples. | + | for the checking. The ''<nowiki>__lookup__</nowiki>'' attribute is a list of strings and tuples. |
Tuples specifies combined lookups, while strings specifies single field | Tuples specifies combined lookups, while strings specifies single field | ||
lookups. The different lookups are tried in the order they are defined in the | lookups. The different lookups are tried in the order they are defined in the | ||
Line 73: | Line 76: | ||
Deletion of objects in the database is done if the shadowobject has its | Deletion of objects in the database is done if the shadowobject has its | ||
''delete''-property set to True. | ''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 186: | 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 204: | 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 ===== |