...

The configuration option 'opconfig_raise_alert_events' (default: true) controls whether opConfig sends any alert events to NMIS.

From opConfig 4.3.2, it is possible to specify a time out per command, that will override the opconfig_plugin_timeout setting, 'plugin_interaction_timeout'.

Collecting device configuration data with a plugin

...

package ReportConditions;
our $VERSION = "0.0.0";
use strict;
sub process_configuration
{
    my (%args) = @_;
    my ($node, $node_info, $command, $configuration_data, 
            $derived, $alerts, $conditions, $logger, $opconfig)
            = @args{qw(node node_info command configuration_data 
derived_info alerts conditions logger opconfig)};
    # ...insert logic that looks at context of command, configuration_data, node etc
    # to determine what conditions and states these imply
    
    return { success => 1,
             conditions => { 
               "ReportConditions" => {
                  "node is lacking something" => 0,
                  "command implies something is in good shape" => 1,
                  "something unexpectedly couldn't be analysed" => undef,
               },
             },
           };
}
1;

How to use a plugin to prepare derived information (or knowledge) for opConfig

A plugin may report extracted 'knowledge', information that it derived from the configuration data, to opConfig for display and storage.
To do so, the plugin must have a process_configuration function that returns a derived_info response.

The derived_info response structure must be a hashref if it is present, and can have any depth.
The outer key is used to separate information reported by different plugins (or different kinds of information); a suitably unique key needs to be chosen by the plugin author.

The following keys have special meaning and should not be used for other purposes in your inner datastructure: type, tag, value, title, labels, rows.

All derived_info data is stored by opConfig, but at this time the opConfig gui will only display derived info entries whose inner structure conforms to the following layout:

• property 'type' must be set to 'table',
• property 'labels' must be an array whose elements are displayed as column headings (setting a label to undef causes this column to be skipped in the display),
• property 'rows' must be an array of arrays whose elements are to be shown as table.
• property 'title' may be set but is optional.

Example Plugin

The following example plugin produces two tabular instances of derived information, which will be displayed by the opConfig GUI, and further example data which will be stored but not displayed.

New Report Condition Elements in opConfig 4.2.1

Report Conditions has been extended to allow passing of structured data, this can be used to show urls, tooltips or buttons to kick off new virtual operator jobs.

Instead of returning a perl list you pass back an array of hashes.

return { success => 1,
          conditions => { 
            "ReportConditions" => [
				{
					message => "Interface has high util",
					url => "http://example.com/kb/interface/util",
					url_label => "KB Interface Util",
  					condition => 1,
				}
			],
          },
        };

Required values for condition elements

URL Cell

You can have the conditions table render a URL cell in one or many rows.

Image Added

push(@foundConditions, {
  message=> "Interface $interface has HIGH percentage of INPUT packets being switched by the processor.",
  url => "http://example.com/knowlege",
  url_label => "Knowledge Base",
  condition => 1,
}); 

Tooltips

Render a link which when the user clicks displays a tooltip.

Image Added

push(@foundConditions, {
  message=>"Interface $interface has HIGH percentage of OUTPUT packets being switched by the processor.",
  tooltip => "This is a bad thing, you should release the monkeys",
  condition => 0,
}); 

Tagging

Image Added

push(@foundConditions,{
  message=>"Interface $interface has HIGH percentage of input errors.",
  ts_tag=>'interface_errors',
  condition => 1
});

How to use a plugin to prepare derived information (or knowledge) for opConfig

A plugin may report extracted 'knowledge', information that it derived from the configuration data, to opConfig for display and storage.
To do so, the plugin must have a process_configuration function that returns a derived_info response.

The derived_info response structure must be a hashref if it is present, and can have any depth.
The outer key is used to separate information reported by different plugins (or different kinds of information); a suitably unique key needs to be chosen by the plugin author.

The following keys have special meaning and should not be used for other purposes in your inner datastructure: type, tag, value, title, labels, rows.

All derived_info data is stored by opConfig, but at this time the opConfig gui will only display derived info entries whose inner structure conforms to the following layout:

• property 'type' must be set to 'table',
• property 'labels' must be an array whose elements are displayed as column headings (setting a label to undef causes this column to be skipped in the display),
• property 'rows' must be an array of arrays whose elements are to be shown as table.
• property 'title' may be set but is optional.

Example Plugin

The following example plugin produces two tabular instances of derived information, which will be displayed by the opConfig GUI, and further example data which will be stored but not displayed.

package DerivedInfo;
our $VERSION = "0.0.0";
use strict;
sub process_configuration
{
    my (%args) = @_;
    my ($node, $node_info, $command, $configuration_data, 
            $derived, $alerts, $conditions, $logger, $opconfig)

package DerivedInfo;
our $VERSION = "0.0.0";
use strict;
sub process_configuration
{
    my (%args) = @_;
    my ($node, $node_info, $command, $configuration_data, 
            $derived, $alerts, $conditions, $logger, $opconfig)
            = @args{qw(node node_info command configuration_data 
              derived_info alerts conditions logger opconfig)};
    # ...insert logic that derives knowledge from the context
    
    return { success => 1,
             derived_info => {
                     
               some_reportable_thing =>
               {
                 type => "table",
                 title => "Reported by ".__PACKAGE__,
                 labels => [ 'one col', 'another col', ],
                 rows => [ [ 'maybe key', 'maybe value', ],
                           [ 'maybe key2', 'maybe value', ],
                    = @args{qw(node node_info command configuration_data 
  [ 'last row', 'last value', ],
       derived_info alerts conditions logger opconfig)};
    # ...insert logic that derives knowledge from the   ],context
    
    return { success     }=> 1,
               my_filtered_tablederived_info => {
                 type => 'table',
  
               labelssome_reportable_thing =>
 [  'first col', 'second', undef, 'and at long last' ],     {
                 rowstype => [ "table",
                 title => "Reported by ".__PACKAGE__,
      [ 'note that', 'there is', 'a gap', 'something that you were notlabels meant=> to[ see'one ]col',
 'another col', ],
                 rows => [ [ 'maybe key', 'maybe [value', 1],
 2, 3, 4, ],
                       [ 'maybe key2', 'maybe value', ],
                },
           [ 'last row', 'last value', ],
         
               ours_but_not_displayed => ],
               {},
                 doesnt_displaymy_filtered_table => "whatever",{
                 storedtype =>  [ 4, 7, 29'table',
                 labels => [ 'first col', 'second', undef, 'and at long last' ],
                 deep_is_ok => { other => { thing => [ 1..10 ],  } },
               },
             },
    };
}
1  rows => [ 
                           [ 'note that', 'there is', 'a gap', 'something that you were not meant to see' ],
                           [ 1, 2, 3, 4, ],
                         ],
               },
                         
               ours_but_not_displayed =>
               {
                 doesnt_display => "whatever",
                 stored =>  [ 4, 7, 29 ],
                 deep_is_ok => { other => { thing => [ 1..10 ],  } },
               },
             },
    };
}
1;

New Derived Information Elements in opConfig 4.2.1

opConfig now supports a hash element being part of the derived data rows array. This allows greater flexibility in displaying data to the user and generating troubleshooting workflows.

Virtual Operator Parameters

Gives the user an opportunity to create a new virtual operator job with predefined parameters, clicking the link takes the user to the Virtual Operator Job form and all values are prefilled out.

For example we could have a command_set called "ping" which accepts the parameter $ipaddress. We could pass the ip of the interfaces opConfig has just collected. This creates chainable jobs which can create a powerful troubleshooting workflow.

Image Added

push(@mtr_table, ["Item 1", "Item 2", {command_set => "ping", parameters => { ipaddress => "1.1.1.1"}}]);
push(@mtr_table, ["Item 1", "Item 2", {command_set => "ping", parameters => { ipaddress => "8.8.8.8"}}]);

Related Virtual Operator Job

In opConfig plugins you can tigger new jobs to be run and have the job_id returned in the current context, if you create a related_job cell and pass in the job_id opConfig will render a cell with a link through to the job your triggered.

Image Added

push(@mtr_table, ["Item 1", "Item 2", {related_job => $job_id_1, related_job_label => "Custom Label"}]);
push(@mtr_table, ["Item 1", "Item 2", {related_job => $job_id_2}]);

Plugin Input Argument Structures

...