Table of Contents
Table of Contents |
---|
...
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_iteraction_timeout'.
Collecting device configuration data with a plugin
...
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.
Key | Valye |
---|---|
command_set | String, name of the command_set you wish the user to run |
parameters | Hash of parameters you wish to give to the virtual operator job |
Code Block | ||
---|---|---|
| ||
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"}}]); |
...
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.
key | value |
---|---|
related_job | ID of a queued or run virtual operator job |
related_job_label | (optional) String for the related job link, if none is given it show "Related Job" |
Code Block | ||
---|---|---|
| ||
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}]); |
...