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 Last revision Both sides next revision | ||
|
devel:blueprints:ipdevpoll [2009/07/13 13:57] klette Updated storage information and some core specifications |
devel:blueprints:ipdevpoll [2009/10/26 09:21] klette |
||
|---|---|---|---|
| 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 ===== | ||
devel/blueprints/ipdevpoll.txt · Last modified: 2012/05/07 11:26 by morten
Page Tools
