How-To Create Custom Quick Actions in opConfig

First things first

Before creating the quick action you will need to have your Command Set file created. opConfig lets you organize whatever commands you'd like it to run into an arbitrary number of groups which we call command sets. Let's create a basic command set using df for the purposes of this How-To however, these command sets can be as simple or complicated as needed to complete the required tasks.

Step 1. Create your Command Set:

Command sets are stored in the single file conf/command_sets.nmis in opConfig before 2.2.4, and since 2.2.4 opConfig supports this and individual command set files in conf/command_sets.d/. It is recommended that you use individual files (as that makes things easier to maintain and more robust, e.g. should one file have syntactical problems). For backwards compatibility the old single file is consulted first, then any individual ones. opConfig loads a command set when it's seen for the first time, and any subsequent occurrences of a clashing config set (i.e. same name) will be ignored but logged.

Navigate to the /usr/local/omk/conf/command_sets.d directory and create a new Command Set file. For this example I will be creating the file df_test.nmis.

cd /usr/local/omk/conf/command_sets.d 
vi df_test.nmis

A command set definition consists of these types of information:

• meta-information like the command set's name (which can be used in CRON to determine when / how often this command set is run),
• optional control information like scheduling constraints and an expiration policy for the commands in that set,
• filters for selecting which devices/nodes the command set should apply to. These are discussed in more detail below.
• and finally the list of the actual commands to be run (which may also have certain modifiers and meta-data attached to them).

%hash = (

  'DF_Test' => {
    'os_info' => {
      'os' => '/(Linux|CentOS|Ubuntu)/'
    },
    'scheduling_info' => {
      'run_commands_on_separate_connection' => 'false',
    },
    'commands' => [
      {
        'privileged' => 'false',
        'command' => 'df',
        'exec' => 'df',
        'tags' => ['Linux','DF','operations'],
      },
    ],
  },
);

Defining which nodes a command set applies to

This is normally done by filtering by OS info, but not necessarily limited to OS info only:

#filter using both regular expression and string equality checks:
'os_info' => {
 'version' => '/12.2|12.4|15.0/',
 'os' => 'IOS'
},
# or just the specific os family/type and that's all:
'os_info' => {
 'os' => '/(Linux|CentOS|Ubuntu)/'
},

The examples above specify that the node in question must have an os_info property set, with sub-properties  os and version in the first example and just os in the second.

Plain string values indicate string comparison, but regular expressions can be given too. A node is only considered for this particular command set if all filtering expressions match. You can filter on any node property, not just properties from os_info (but the default command sets only use os_info).

Prior to version 3.1.1, opConfig considered command sets without filter blocks as disabled; for these versions you may want a 'wildcard' filter matching anything whatsoever,  which can be achieved by adding an os_info filter block with a 'match-everything' regular expression for os, e.g 'os' => '/.*/'.

From opConfig 3.1.1 onwards a command set without filter is interpreted as to apply to all nodes without any restriction.

Quick Actions

Quick actions are templates for new Virtual Operator jobs, we have shipped four sample jobs but you can create your own. Clicking the quick action button will take you too a new virtual operator screen and fill out the specified fields. The default four jobs are defined in the file: /usr/local/omk/lib/json/opConfig/table_schemas/opConfig_action-elements.json

Create your own Quick Action

You can create your own Quick Actions by copying the /usr/local/omk/lib/json/opConfig/table_schemas/opConfig_action-elements.json file to /usr/local/omk/conf/table_schemas/ (you may need to create the table_schemas folder if it does not exist) and then editing it. Available field options are described below.