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:10] 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 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.1247494225.txt.gz ยท Last modified: 2009/07/13 14:10 by klette
Page Tools
