...

The tool opnode_admin.pl lets you list, export, create, modify or delete nodes from the command line. Editing operations involve an export to a JSON file, which you then modify using an editor or other tool of choice, followed by an update of the node using that JSON file. The opnode_admin.pl tool is pretty self-explanatory and documented on this page.

Dealing with slow nodes: using Device Presets

opConfig cannot let one misbehaving device block progress for all others; therefore all interactions with remote devices are subject to a timeout (configuration item opconfig_command_timeout, default: 20 seconds). This timeout is shared by all nodes.

From version 3.0.7 onwards, opConfig  offers Device Presets: a more fine-grained mechanism for adjusting the timing for each node.
Device presets are configured in conf/opCommon.nmisn, under the key opconfig_device_presets. Here is the default setting as shipped with opConfig 3.0.7:

'opconfig_device_presets' => {
  'normal' => { wake_up => 0, settling_time => 0, timeout_factor => 1 },
  'slow' => { wake_up => 2, settling_time => 5, timeout_factor => 1.25 },
},

A device preset can provide adjustments using the following three properties:

• wake_up controls whether a slow login process (that has timed out) should be 'revived' by sending an 'enter' keystroke to wake the device.
  The default is 0, or no extra 'wake up' keystrokes and if the login times out,  the connection is terminated.
  With a positive value N for wake_up, opConfig  will send a wake up keystroke, then wait for a prompt up to the configured timeout, and retry this sequence up to N times.
  If no prompt is detected during that sequence, the connection is terminated.
  Please note that the default for versions before 3.0.7 for wake_up was 1, ie. one login retry. Under certain circumstances and with devices responding excessively slowly this could lead to misinterpreted command outputs and data corruption.
• settling_time controls whether opConfig should wait an extra N seconds for stray output after the login is done but before issuing the first command.
  This setting is meant for compensating for overly slow and/or complex logins with extra banners and the like, which can cause opConfig to mis-trigger on a premature, undesirable prompt if the device in question responds overly slowly. Any output that arrives between the login and the end of the settling period is consumed and discarded. The default values is 0, or no extra compensation delay.
• timeout_factor allows the setup of a longer or shorter interaction timeout for particular devices.
  This option accepts positive values, and the configured opconfig_command_timeout is scaled by that factor for any device that uses this device preset.
  The default value is 1, i.e. no scaling. In the example above and with the default opconfig_command_timeout of 20 seconds, devices marked with the "slow" preset would get a timeout of 25 seconds.

In the GUI, assigning a device preset to a device is done on the Edit Node page, on the Connection tab.
On the command line  you can use opnode_admin.pl act=set node=<somenode> entry.connection_info.device_preset=<presetname> to select a preset for a node.

A node without preset  is subject to the default values.

Managing Command Sets

As mentioned above opConfig lets you organize whatever commands you'd like it to run into an arbitrary number of groups which we call command sets.

...

# for all commands in a set, define this in the command set - note the S in run_commandS_...!
'scheduling_info' => {
 'run_commands_on_separate_connection' => 'true'
},

# for just a specific command, set this for the command in question - no S in run_command_...!
commands => [
 {
 'command' => 'show version',
 'run_command_on_separate_connection' => 'true',
 }]

Dealing with particular slow commands: Recovering from

...

timeouts

opConfig doesn't block indefinitely if a command on a device doesn't return a response; instead the session times out after a configurable period (see config  item opconfig_command_timeout, default 20 seconds) and the command is marked as failed.

...