devel:blueprints:ipdevpoll
Differences
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] 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 ===== | ||
devel/blueprints/ipdevpoll.txt · Last modified: 2012/05/07 11:26 by morten
Page Tools
