Page History

NMIS code plugins are meant to augment and extend the update and collect functionality, if and when classic modelling doesn't suffice to handle a
particular scenario.

Each plugin must be valid perl, be named X.pm, must have a 'package X;' line, and its package name must not clash with the other NMIS components. the plugin MUST NOT use Exporter to export anything from its namespace.

It's recommended that the plugin have a version declaration right after the package line, i.e. 'our $VERSION = "1.2.3";'

The plugin may load extra perl modules with use or require, but it must not use any package-level global variables. all its variables and any objects that it might create must have local scope.

A plugin can offer one or more of the functions update_plugin(), collect_plugin() after_update_plugin() or after_collect_plugin().

...

• (0 or undef,rest ignored) means no changes were made, or that the plugin declined to run altogether (for example, because the environment  doesn't match the plugin's needs
• (1,rest ignored) means changes were made to the sys object, and nmis should save the nodeinfo and view components.
• (2,list of error messages) means the plugin failed to work and NMIS should please log the error messages. no nodeinfo/view saving will be performed.

How to access the information in NMIS9

Nodes

We can access the node object using the object sys: 

my $node_obj = $S->nmisng_node

Collected Data - As Interfaces

We All the collected data is saved in a new structure called inventory. We can use as many filters that we need:

my $host_ids = $node_obj->get_inventory_ids(
		concept => "Host_Storage",
		filter => { historic => 0 });

Log

We can log any message by using the NMISNG object: 

$NG->log->info("Working on $node Host Memory Calculations");

Example

You can see a complete example of a collect plugin in the Host_Resources plugin (Released in 9.1.2).