NAV Wiki

User Tools

Site Tools

Trace: • navref_241017 • database • navref_231018 • consolidated-interface-table • dhcp-checker • writing_plugins • ipdevpoll • django_template
devel:blueprints:ipdevpoll

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
devel:blueprints:ipdevpoll [2009/07/13 13:57] – Updated storage information and some core specifications klettedevel:blueprints:ipdevpoll [2012/05/07 11:26] (current) – fix url morten
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 =====
devel/blueprints/ipdevpoll.1247493430.txt.gz · Last modified: by klette
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki