Create a Custom Action
To define either an On-Demand Action or a Lifecycle Action, click the New Action link in the Actions Library page. This brings you to the New Action form. This form has three section you must complete before you can save the action:
- General Settings Section – Defines action category, action type, where the action executes, and timeout value.
Resource Mapping Section – Defines which resources this action may be executed against.
Complete each section of the New Action form as described below.
General Settings Section
When you first create a new action, the General Settings section will be displayed at the beginning of the New Action form as shown below.
Follow this procedure to complete the fields in this section.
- Choose the action category: On-Demand or Lifecycle.
Choose the action type. The table below summarizes the possible action types for on-demand actions. For lifecycle actions, the only available action type is Command or Script.
Type Description Invoke a Web Service Executes the designated web service request against a VM, deployment, or application profile. Command or Script (Default)
Executes the designated command or script against a VM.
If you provide scripts that need to be executed as part of Action Library, be aware that a script is considered to be successful based on OS exit codes for script execution. This behavior is consistent with scripts that are run directly on a Windows or Linux server using their respective shells. Once a script is executed on Linux or Windows, the output shown on running echo $?, is the status code.
- On Linux, script execution will be marked as Failed only if the script's last line failed to execute. In all other cases it will be marked as successful.
- On Windows, scripts will be marked as Failed only if an explicit Exception is thrown.
For user-provided scripts, the onus is on the user to ensure that the script exits successfully.
This type additionally allows you to specify the following options:
- Where to run this type of action:
- On the VM – Requires that management agent is installed.
- Externally – In a script execution container in the management cluster, if Cloud Remote is not used to connect with the region where the VM is deployed, or in a script execution container in the Cloud Remote cluster, if Cloud Remote is used for the region.
- Reboot the VM after action execution – If the action creator determines that a reboot is required after the action execution, then end users using this action do not need to manually perform this extra step. This switch is only available for On-Demand Actions.
- Sync VM information after action execution – This causes Workload Manager to update its VM information with the latest VM metadata provided by the cloud region. You can perform this operation in bulk by multi-selecting several VMs, or just for one VM. This switch is only available for On-Demand Actions.
The possible execution modes for this option are based on your Execute from Bundle setting that is explained in the Action Definition Section later in this page:
- Download From Bundle is True
- The content in Script From Bundle is presumed to be a script inside the bundle specified.
- The bundle is presumed to be an archive (zip/tar/tgz/tar.gz) that is extracted and the file is searched and executed along with any other command line parameters.
- Download From Bundle is False
- The content in the Executable Command field is presumed to be a series of commands separated by semicolons.
- A special case is that the first command in this series of commands can be a Script URL. Thus the first command, if a script URL, is processed by first downloading the script and then it is executed along with the rest of the following commands.
Causes a Puppet role to be enforced against a VM.
To run Puppet actions on Workload Manager instance, you must first disable the requiretty setting for that instance in the /etc/sudoers file.
Invoke Cisco UCS Director Workflow Causes a workflow defined in a UCS Director server to be executed against a VM. Input parameters for the workflow defined in UCS Director are displayed to the Workload Manager user in a data entry dialog box when Chef
Causes a Chef run list to be run against a VM.
Causes a Ansible playbook to be run against a VM.
- Specify the Action Name, Description, and Action Timeout.
Resource Mapping Section
The function of the Resource Mapping section is to qualify where an action may be made available. The appearance of this section changes based on what type of action is specified in the General Settings section. If the action specified is Invoke a web service, the user must first specify whether the action is directed against a deployment, VM, or application profile. If the user selects any other action type in the General Settings section, the action is always executed against a VM. If the action is executed against a deployment or a VM, the Where To Apply options must also be selected.
The following table identifies the available resource types for each action type and their associated Where To Apply options.
|Action Type||Resource Type||Where to Apply Options|
|Invoke a Web Service|
|Workload Manager Deployed VMs|
Workload Manager Deployed VMs
To complete the Resource Mapping section, follow the instructions below based on the action type you selected in the General Settings section.
Resource Mapping for Actions Other Than Invoke a Web Service
If you select any action type other than Invoke a web service, the action is executed against a VM and the Resource Mapping section appears as shown below.
Clicking on the Add Resource Mapping link displays the following dialog box:
Selecting the resource type will cause the list of Where To Apply parameters to change as summarized in the table above.
Select the resource type (Workload Manager Deployed VMs or Imported VMs), select the Where To Apply options from each of the dropdown menus, and then click Done. This will cause a resource mapping to be displayed in the Resource Mapping section as shown below.
Repeat this process as many times as needed to add all of your resource mappings. You can delete a resource mapping by clicking the corresponding trash can icon in the Actions column.
Resource Mapping for the Invoke a Web Service Action
If you select the Invoke a web service action type in the General Settings section, the action may be executed against a deployment, a VM, or an application profile; therefore the Resource Mapping section changes to include a dropdown menu labeled Select Resource To Map as shown below.
The default value for Select Resource To Map is Deployments. If you now click the Add Resource Mapping button, a resource mapping dialog box for Deployments is displayed as shown below.
Select the Where To Apply options from each of the dropdown menus, and then click Done. This will cause a new resource mapping to be displayed in the Resource Mapping section. Add and delete mappings as needed.
If you click on the Select Resource To Map dropdown and change it to Virtual Machines, clicking the Add Resource Mapping link caused the resource mapping dialog box for VMs to appear as described in the Resource Mapping for Actions Other Than Invoke a Web Service section above.
If you click on the Select Resource To Map dropdown and change it to Application Profiles, the Add Resource Mapping link disappears and is replaced with the message shown below.
Action Definition Section
The input fields for the Action Definition section change The following table identifies the available Type along with a brief description and identifies the permitted resources for Resource Mapping.
|Invoke a Web Service|
|The transfer protocol to be used by this action when invoking the service – select HTTP or HTTPS.|
Web Service URL
The URL used for the web service using the following format:
Use Case: You can also introduce a custom parameter in the Web Service URL field and define that parameter in the Custom Fields section (described below). For example, if you introduce a custom parameter called call the URL as shown in the following screenshot.
Define the call parameter in the Custom Fields section to ensure that this parameter is replaced by the value defined in that section. The following screenshot shows the Custom Fields section.
|Username and Password:||Credentials required to issue the web service call|
|HTTP Request Type|
|Content Type||If the body content should be sent using the JSON or XML format|
|Body||The request body contents to be used when issuing the API call for this action.|
|Command or Script (Default)|
Execute From Bundle
If you choose to configure this setting, provide the following details:
If you choose to configure this option, provide the command that should be executed as part of the custom action.
A Puppet server that is maintained by the user can be added to the CloudCenter repository list. (See Artifact Repository to configure a repository). A Puppet server configured in Workload Manager as a shared repository is referred to as a Puppet repository. If multiple Puppet repositories exist, they are listed in the dropdown menu and you must pick one of the configured Puppet repositories in this field, as shown in the following screenshot.
|Role||A role that must exist in the Puppet repository configured above. For example wordpress.|
|Environment||The Puppet environment where this action should be executed. For example, production.|
|Invoke Cisco UCS Director Workflow||API Key||The API key for the UCS Director.|
The IP address of the UCS Director.
The name of the workflow created in the UCS Director.
All of the workflow user input fields configured in the workflow in the UCS Director, as shown in the following screenshot...
... are displayed in a data input dialog box in Workload Manager when the action is invoked, as shown in the following screenshot.
A Chef server that is maintained by the user can be added to the CloudCenter repository list. (See Artifact Repository to configure a repository). A Chef server configured in Workload Manager as a shared repository is referred to as a Chef repository. If multiple Chef repositories exist, they are listed in the dropdown menu and you must pick one of the configured Chef repositories in this field. The following screenshot shows an example.
|Organization||The company or department details. In this example, cliqrtech|
|Environment||The Chef environment where this action should be executed. In this example, default.|
The combination of the cookbook name and recipe name using the cookbook::recipe format – in this example, jenkins::master
An Ansible server that is maintained by the user can be added to the CloudCenter repository list. (See Artifact Repository to configure a repository). An Ansible server configured in Workload Manager as a shared repository is referred to as an Ansible repository. If multiple Ansible repositories exist, they are listed in the dropdown menu and you must pick one of the configured Ansible repositories in this field.
|Playbook||The Ansible playbook path is jenkins/install.yml.|
Once you complete the required fields in all three section, you can preview the action to see how the action is presented to the end user by clicking the Preview button in the lower right, or you can save the action by clicking the Done button in the lower right.
At bottom of the Action Definition Section you can add optional input fields and make them available for user input.
To add a custom field, click the Add Custom Field link at the bottom of the Action Definition section. This causes the section to expand showing input parameters for defining the custom field, as shown in the screenshot below.
Set the toggles and fields for the custom field as explained in the table below.
|Field / Toggle||Description|
|Visibility toggle||Default is visible. Set to invisible if you do not want to display this custom field in a dialog box during execution of an on-demand action, or during selection in an application profile or service definition or region tab of a lifecycle action. When set to invisible, the Lock toggle and Required Field toggle (see below) are hidden.|
|Lock toggle||Default is unlocked, meaning the user can edit the value of this custom field in a dialog box during execution of an on-demand action, or during selection in an application profile or service definition or region tab of a lifecycle action. Click on the icon to lock it. This prevents the user from changing the value of the field. If this toggle is set to locked, Required Field toggle (see below) is hidden.|
|Display Name||Enter the name that you wish to assign for this custom field. If made visible, this label is displayed to end users when they invoke this action.|
The parameter name that is available to the script execution as environment variables. If these parameters are provided as $parameterName or as %paramName% in the script parameters, Workload Manager replaces this field with the passed value in the script.
|Help Text||Provide additional tips that you wish to provide for the end user to complete in this field. Try using a single, short sentence so your end users are not overwhelmed with too much text.|
See Using Parameters > Parameter Type for details
|Default Value||Assign the default value to be used by the custom field – should the end user not specify any values.|
|Required Field toggle|
Set to YES if the end user must enter information in this field in order for the action to complete.
Repeat adding custom fields as necessary until done. You can delete a custom field by clicking on the the corresponding trash icon.
- No labels