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.
| Code Block |
|---|
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).
| Code Block |
|---|
%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'],
},
],
},
); |
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.jsonClicking the quick action button will take you too a new virtual operator screen and fill out the specified fields.
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.
|
| name | string | Name which is shown at the top of the quick action element |
| description | string | Text shown under the quick action name, useful to describe what the action does |
| command_sets | array of strings | Command set keys which you wish to be run |
| nodes | array of strings | Names of nodes which you wish the command sets to be run against |
| buttonLabel | string | Text of the run button |
| buttonClass | string | Css class applied to the button to colour it.
|
.png?version=1&modificationDate=1587998894000&cacheVersion=1&api=v2&width=759)
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.
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.
A command set definition consists of these types of information:
...
Here is an excerpt from the default command set that ships with opConfig:
|
Defining which nodes a command set applies to
This is normally done by filtering by OS info, but not necssarily limited to OS info only:
|
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.
...