Actions Library

As an action owner, you can perform the following functions on the VM:

• Share actions to permit other users in your tenant or a group member to also access the custom actions as shown in the following screenthot.
  
• Delete actions that you no longer need, as shown in the following screenshot.
  

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.

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.

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.

• System-defined core actions.
• Provided out-of-box by the CloudCenter platform.
• Users cannot modify these actions.
• Platform specific.
• Available on all cloud instances.
• Action Types: The following table identifies the VM action availability for VM resources.

• Core actions to support VM Management tasks on supported clouds.
• Cloud-specific as identified in the Advanced Platform Actions table below.
• Used to reconfigure the VM instance.

• Action Types: The following table identifies the VM action availability, given the current VM state and Cloud type.

  Advance Actions	Description	Current State	Supported Clouds
  Attach Volume	Cisco does not support the attachment of existing volumes that are available in the cloud. If storage types are configured in the CCM, you can opt to input volume parameters. Cisco enables you to select, if the storage types are configured in the CCM, and input the volume parameters using this option.	Running Stopped	Amazon AzureRM (effective CloudCenter 4.9.0) Azure Stack and IBM SoftLayer (effective CloudCenter 4.9.0) OpenStack VMware vCD Google Dimension Data (effective 4.9.1)
  Detach Volume	Detaches the volumes from the existing VM.	Running Stopped
  Sync VM information	Update the current VM information from the CloudCenter platform so the latest VM metadata information is visible.	Running Stopped Started
  Resize Instance Type	Resize or reconfigure the VM's instance type or change the CPU and memory size. Select the instance type configured in the CCM for the required cloud.	Stopped For OpenStack, it is both Running and Stopped states.	Amazon AzureRM and Azure Stack (effective CloudCenter 4.9.0) OpenStack VMware Dimension Data (effective 4.9.1)
  Create Snapshot	Creates the image snapshot for the given VM.	Running Stopped	VMware
  Install CloudCenter Agent	Install the agent on an Imported VM from the CCM UI. See VM Management > Install Agent for additional details. If the latest version of the agent is already installed on a VM, then this action will no longer be available for this VM.	Running	Amazon AzureRM Azure Stack and IBM SoftLayer (effective CloudCenter 4.9.0) OpenStack VMware vCD Google

  For more information on VM states, see Deployment and VM States.

Executes the designated command or script on the VM (see Deployment Lifecycle Scripts or Callout Scripts).

This type additionally allows you to specify the following options:

• Where to run this type of action: 
  • On Virtual Machine OS – On a VM with an agent installed. 
  • Externally – On a Docker container that runs on the CCO (not dependent on the worker image in any way). For example, if you need to configure external CLIs on a Docker container for a specific cloud, you can determine a Custom Field with the CLI items in a list format. See the Custom Field section below for additional details.
• Reboot the VM after action execution – If the action owner 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! An action owner refers to a user who creates (the New Action link) a custom action.
  
• Sync VM information after action execution – This option allows you to update current VM information (for example, size from the cloud) from the CloudCenter platform so the latest VM metadata information like IP addresses are visible. You can perform this operation in bulk by multi-selecting several VMs, or just for one VM.

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
  1. The content in Script From Bundle is presumed to be a script inside the bundle specified. 
  2. 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
  1. The content in the Executable Command field is presumed to be a series of commands separated by semicolons.
  2. 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.

Applicable for both CloudCenter deployed VMs and Imported VMs.  See Puppet for additional context.

The URL used for the web service using the following format:
<host>:<port>/<resource>/<parameter>
For example: webserver.cliqrtech.com:3000/users/post

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.

If you choose to configure this setting, provide the following details:

• Location: Select from a list of previously-configured repositories as described in the Share Artifact Repositories section. If repositories have not been configured, you must use the default URL option and provide the entire URL.
• Relative Path: Specify the path to the folder where the script bundle resides. The CloudCenter platform appends this path to the hostname defined in the repository. All compressed file formats (.tar, .zip, etc.) are acceptable in this field.
• Script from Bundle: Provide the name of the script that this action should use.

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.

1. Download and install the Linux and Windows AgentLite bundle. See VM Management > Download AgentLite Bundle for additional context.
2. Create a New Action to Execute from Bundle.
   

3. Create a tar/tgz bundle for Linux and Zip for Windows, that contain the script files. The sample scripts are available in the following locations:

   #LINUX:
   <AGENT_HOME>/scripts/samples/checkActionSendMessage.sh
   
   #WINDOWS: 
   <AGENT_HOME>\scripts\samples\checkActionSendMessage.ps1

4. The script invokes the actionSendMessage function and sends status messages to the CloudCenter platform.
   Locate the CCM and CCO log files to verify that each sent message is being received. See Locate Log Files for additional context.

   #SAMPLE CCO LOG
   Done executing
   ', status=SUCCEEDED, actionMessages=[ActionMessage
   {id=144354, message='Bundle was downloaded (and extracted if it was a 
   supported archive) at the location: 
   /opt/remoteFiles/checkActionSendMessage', timestamp=2017-08-01 
   02:04:53.458, resourceMessageId=10164, actionMessageStatus=IN_PROGRESS}
   
   
   #SAMPLE CCM LOG
   2017-08-01 02:04:53,782 DEBUG impl.DefaultNodeMessageListener [SimpleAsyncTaskExecutor-1]  - Received Message AgentStatusMessage 
   {
   	status = ActionExecuting
   	jobId = 0
   	nodeId = i-0ebd9fb0
   	taskId = 0
   	actionExecutionId = 9818
   	cloudResourceUniqueId = 4473
   	taskName = 
   	timestamp = Tue Aug 01 02:04:53 UTC 2017
   	helperNode = false
   	data = 
   	msg = ###yes###
   	keyValues = <null>
   	agentVersion = 4.8.2
       agentType = BROWNFIELD
   }

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.

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.

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.

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.