Actions Library
Overview
Actions Library is a framework that extends the CloudCenter platform capabilities by enabling you to create, manage, and execute actions for VM management. This framework allows administrators to define actions and execute them on different CloudCenter resources such a VMs, Deployments, or Application profiles. Association criteria defined as part of an action dictates which action is available for execution against which specific resource.
Cloud Nuances
While the Actions Library is available for all CloudCenter Supported clouds.
Permissions and Access Control
Permissions define certain actions that users can perform. You can control the permissions for a custom action. See Permission Control > Actions Library Permissions for additional context.
The Actions Library Tab
The Actions Library tab in the CCM UI lists the custom actions that are created by users, as shown in the following screenshot.
The numbers provided in the screenshot above are identified as the following table describes.
Markup No. | Identifier | Description |
---|---|---|
1 | Actions Library tab | Location to view and manage all custom actions in the CloudCenter platform. |
2 | Search icon | Enter the name of the custom action to search for the action – this function is useful if you create numerous actions that do not display on this page. |
3 | Actions dropdown | As an action owner, you can perform the following functions on the VM:
|
4 | Export icon | Export the entire list of custom actions displayed in the Actions Library tab to a actions.json file – this function is useful if you want to copy the same actions across CloudCenter installations or across different tenant hierarchies. The following screenshot shows an example. |
5 | Import icon | Import actions used on VMs outside this CloudCenter instance and add it to the list of custom actions – this function is useful if you have multiple instances of CloudCenter and need to configure the same custom actions in all CloudCenter instances. The import function allows you to get (import) the actions defined in another CloudCenter instance or tenant hierarchy into the current CloudCenter instance. The following screenshot shows the Import Library dialog box. |
6 | Enable (default) or Disable actions | Enable (default) or Disable the action in the Actions Library page, as shown in the following screenshot... ...so it is available/not available on the VM page, as shown in the following screenshot. Users who only have View permissions on these action cannot toggle this visibility. This setting is controlled by the action owner. See Permission Control for additional context. |
Types of VM Actions
The types of actions available and visible for each VM for each user depends on the following factors:
The cloud being used (see Cloud Nuances for additional context).
The OS being used (see Platform actions and VM Management > Install CloudCenter Agent for additional context).
The current state of the VM, running or stopped, or other (see Platform Actions for additional context).
The permissions for the user implementing the action (see Permissions and Access Control for additional context).
The configured object mapping of custom action (see Custom Actions for additional context).
When you manage Virtual Machines, you can perform two types of actions that are executable on individual VMs or on multiple VMs as a batch.
Platform Actions: See the Platform Actions section below for additional details.
Custom Actions: See the Custom Actions section below for additional details.
Additionally, you can model the Invoke a Web Service custom action to appear for Application Profiles, Deployments, or Virtual Machines. See Custom Actions section below for additional details.
Platform Actions
Platform actions are defined by Cisco for the CloudCenter platform. You cannot modify or manage these actions – you can perform these when required on both CloudCenter Deployed and Imported VMs. The following table describes the platform actions.
Basic Platform Actions | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
Advanced Platform Actions | ||||||||||||||||||||||||||
|
Custom Actions
You can define custom actions for CloudCenter deployed VM or imported VMs, and in some cases, even Deployments and Application Profiles by clicking the New Action link in the Actions Library page.
Defining Custom Actions
Every custom action that you define in the Custom Actions tab has the following areas of interaction:
General Settings – identifies general data.
Object Mappings – identifies where this action should be applied.
Action Definition – identifies how the execution should be executed. All supported action types have some default fields as well as the ability to enrich the action with Custom Fields. See the Action Definition section below for additional context.
After configuring the action, you can preview the action to see how the action is presented to the end user.
General Settings Section
Define the action properties (type, name, description) and identifies if the action must be executed internally or on a container.
The Action Timeout field allows you to program the action to timeout within a specified limit and defaults to 20 minutes. This field along with the Type, Action Name, and Description fields is available for all custom actions.
After you define an action, you cannot change the action type.
The following table identifies the available custom action Type along with a description and identifies examples for when you might use each type.
Type | Description |
---|---|
Invoke a Web Service | Executes the designated web service request. For example, you can use this action type if you publish an application profile in your ServiceNow catalog. |
Command or Script (Default) | Executes the designated command or script on the VM (see Deployment Lifecycle Scripts or Callout Scripts). 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.
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:
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:
|
Invoke Cisco UCS Director Workflow | Only applicable for VMs that invoke the workflow in a UCSD server (see Configure a Cisco UCSD Cloud for additional context). |
Chef | Applicable for both CloudCenter deployed VMs and Imported VMs. See Chef for additional context. |
Puppet | Applicable for both CloudCenter deployed VMs and Imported VMs. See Puppet for additional context. To run Puppet actions on CloudCenter instance, you must first disable the requiretty setting for that instance in the /etc/sudoers file. |
Ansible | Applicable for both CloudCenter deployed VMs and Imported VMs. |
Object Mapping Section
Configure at least one or more mappings for each action by specifying the type of custom actions to apply this action so end users can view and invoke the permitted action.
You cannot invoke custom actions from the Job Details page. Navigate to the VM details page or the Virtual Machine tab to view and invoke an action.
Once you add mappings, the Object Mapping area displays the objects by order of highest priority (ALL). You can directly delete unwanted mappings by clicking the Delete icon. You can configure any number of mappings for a custom action – multiple mappings gives action creators the flexibility and power to define the granularity of a mapping on both CloudCenter deployed or Imported VMs. The following screenshot shows the Object Mapping area and the table after the image provides details on every action type.
This section is key to using any Action type. More details on default and custom fields are captured below.
The following table identifies the available Type along with a brief description and identifies the permitted resources for Object Mapping, and each map automatically lists the corresponding fields that you can configure for each map.
Type | Object Mapping (Permitted Resources) | Description |
---|---|---|
Invoke a Web Service | Deployment |
|
Virtual Machines |
| |
Application Profiles | This option does not contain any configurable fields as the action is applied to all Application Profiles. | |
| CloudCenter Deployed VMs |
|
Imported VMs (with agent installed) |
|
Action Definition Section
The following table identifies the available Type along with a brief description and identifies the permitted resources for Object Mapping.
Type | Fields | Notes |
---|---|---|
Invoke a Web Service | Protocol | 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:
Use Case: To create a new custom action called Add Web Service, use a custom script that already contains the parameter definitions. When you call the script, the defined parameters are displayed in the Custom Fields section. For example, if you had defined two custom parameters called PRM1 to display Test and PRM2 to display Hello in the script and configured the parameters to obtain their values from a webservice type, as shown in the following screenshot. Then the custom values are displayed in the resulting popup for this custom action. Preview the Add Web Service popup by clicking the Preview button located in the lower right corner of the New Action page. The following screenshot shows a preview popup. When end users see this popup, they can select a value displayed in the dropdown, as shown in the following screenshot. After you save the new custom action, the Add Web Service action is displayed with the other actions for this VM, as shown in the following screenshot.: The newly configured Add-Web-Service action popup displays the type of action and the Node name to identity the action being used in the action. When you use this custom action, you see the History tab updated with the relevant details. This action required two numbers to be added, and the sum of those numbers is displayed (and highlighted) in the History logs. The following screenshot shows the History tab. Imported VMs with AgentLite installed can execute custom scripts/commands that can additionally send status messages back to the CloudCenter platform if you invoke the actionSendMessage function within your scripts for custom actions. To invoke the actionSendMessage function, follow this procedure.
|
Executable Command | If you choose to configure this option, provide the command that should be executed as part of the custom action. | |
Invoke Cisco UCS Director Workflow | API Key | The API key for the UCSD server. |
UCSD Server | The IP address of the UCSD server. | |
Workflow Name | The name of the workflow created in the UCSD serve – gshar in example that the following screenshot shows. This workflow is automatically called by the custom action that you create in the CloudCenter platform, as shown in the following screenshot. All the fields configured in the workflow on the UCSD server, as shown in the following screenshot... ... are displayed in the custom action popup in the CloudCenter platform, as shown in the following screenshot. | |
Chef | Chef Server | A Chef server that is maintained by the user can be added to the CloudCenter repository list (see Share Artifact Repositories to configure a repository). A Chef server configured in a CloudCenter platform 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. When executed, this action displays in the VM page as shown in the following screenshot. In response, the file is executed and the status message is displayed along with the logs and details being updated. |
Organization | The company or department details. In this example, cliqrtech | |
Environment | The deployment environment where this action should be executed. In this example, default. | |
Run List | The combination of the cookbook name and recipe name using the cookbook::recipe format – in this example, jenkins::master | |
Puppet | Puppet Server | A Puppet server that is maintained by the user can be added to the CloudCenter repository list (see Share Artifact Repositories to configure a repository). A Puppet server configured in a CloudCenter platform 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. When you call the custom action in the VM page, you will not see any custom fields if none have been defined. The following screenshot shows an example. In response, the file is executed and the status message is displayed along with the logs and details being updated. |
Role | A role that must exist in the Puppet repository configured above. For example wordpress. | |
Environment | The deployment environment where this action should be executed. For example, production. | |
Ansible | Repository | An Ansible server that is maintained by the user can be added to the CloudCenter repository list (see Share Artifact Repositories to configure a repository). An Ansible server configured in a CloudCenter platform 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, as shown in the following screenshot. When you call the custom action in the VM page, you will not see any custom fields if none have been defined. The following screenshot shows an example. In response, the file is executed and the status message is displayed along with the logs and details being updated. |
Playbook | The playbook path is jenkins/install.yml. |
Custom Fields
Add optional custom fields to the custom action to enrich the action by getting specific inputs from users.
The following screenshot shows an example of configuring a specific set of commands by using the Custom Fields option so the user can select one of the commands and launch the action on an external Docker container – the configuration displays on the left and the resulting popup on the right:
Provide the information that the following table describes for each custom field that you add for a custom action.
Custom Field | Description | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Display Name | Required. Enter the name that you wish to assign for this custom field. If made visible, this label is displayed to end users when they invoking this action. | ||||||||||||||||||||||||||||||
Param Name | 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, the CloudCenter platform 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. | ||||||||||||||||||||||||||||||
Type | Click here to expand...
The Type dropdown enables you to determine your own value for a custom field: by selecting one of the following options from the Type dropdown list.
| ||||||||||||||||||||||||||||||
Default Value | Assign the default value to be used by the custom field – should the end user not specify any values. | ||||||||||||||||||||||||||||||
Required Field | Identify if the end user must enter information in this field in order for the action to complete. |
Failure Behavior
If any action fails when being called, the CloudCenter platform displays the failure in the History page (next to the event as highlighted in the following image). Additionally, if the failure reason is too long, you see a View Details link that provides the entire context of the error. The following screenshot shows the History page.