Actions Library

Overview

Actions Library is a framework that extends Workload Manager 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 Workload Manager 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

Actions Library is available for all 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 Workload Manager 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.IdentifierDescription
1Actions Library tabLocation to view and manage all custom actions in Workload Manager.
2Search iconEnter 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.
3Actions dropdown

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.
  • Delete actions that you no longer need.

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 Workload Manager installations or across different tenant hierarchies. The following screenshot shows the JSON file that you can download based on your browser preferences.

5Import icon

Import actions used on VMs outside this Workload Manager instance and add it to the list of custom actions – this function is useful if you have multiple instances of Workload Manager and need to configure the same custom actions in all Workload Manager instances. The import function allows you to get (import) the actions defined in another Workload Manager instance or tenant hierarchy into the current Workload Manager 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 so it is available/not available on the VM page.

Users who only have View permissions on these actions 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 Virtual Machine Management > Install Workload Manager 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 resource mapping of custom action (see Custom Actions for additional context).

When you manage VMs, you can perform two types of actions that are executable on individual VMs or on multiple VMs as a batch.

  • Platform Actions: Platform actions are defined by Cisco for Workload Manager. You cannot modify or manage these actions – you can perform these when required on both Workload Manager Deployed and Imported VMs. See the Platform Actions section below for additional details.

  • Custom Actions:  Custom actions are defined by Workload Manager resource owners and users. The action owner can modify these actions that are available on all cloud instances. You can execute the action On Virtual Machine OS that has the latest Workload Manager agent version or Externally so it is available to all VMs managed by the Cloud Remote platform.Custom actions can be of two types:

    • On-Demand Actions: See the On-Demand Actions section below for additional details.

    • Lifecycle Actions: See the Lifecycle Actions section below for additional details.

Platform Actions

The following table describes the platform actions.

Basic Platform Actions

  • System-defined core actions.
  • Provided out-of-box by Workload Manager.
  • 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.
Basic ActionsDescriptionVM Resources (Resources)
StartPower on and start the VMManaged VM
StopStop and power off the VMManaged VM
RebootAttempts a graceful shut down and restart of the VMManaged VM
Terminate

Stops and Remove the VM from the cloud.

  • Managed VM
  • Unmanaged VM
Import to Workload ManagerImport a VM from the Unmanaged tab into the Managed category. See Virtual Machine Management for additional context.Unmanaged VM
Upgrade Agent

Upgrade the agent on a Managed VM to the latest released Workload Manager agent version from the Workload Manager UI. See Virtual Machine Management > Upgrade Agent for additional details.

You can only upgrade a VM running CloudCenter Legacy 4.7.3 or later versions.

See Virtual Machine 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.

Managed VM

Advanced Platform Actions

  • Core actions to support Virtual Machine 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

DescriptionCurrent StateSupported Clouds

Attach Volume


Cisco does not support the attachment of existing volumes that are available in the cloud. If storage types are configured in Workload Manager, you can opt to input volume parameters.

Cisco enables you to select, if the storage types are configured in Workload Manager, and input the volume parameters using this option.

  • Running
  • Stopped

  • Amazon
  • AzureRM
  • OpenStack
  • VMware

  • Google

Detach VolumeDetaches the volumes from the existing VM.
  • Running
  • Stopped

Sync VM information

Update the current VM information from Workload Managerso 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 CCM for the required cloud.

 Google Cloud Platform Nuance

If the VM is upgraded to a 96-CPU instance type (e.g. n1-highcpu-96), the platform will be changed to the Skylake Platform. However, if the VM is downgraded to a lower CPU from 96-CPU instance type, the platform will be remain the Skylake Platform

 vCenter Nuance

When you attempt to resize a vCenter VM, the dialog box for selecting the new instance type has two toggles that are set to Off by default: Stop instance before resizing, and Start instance after resizing.

Stopped

For OpenStack, it is both Running and Stopped states.

  • Amazon
  • AzureRM
  • OpenStack

  • VMware

  • Google Cloud Platform

Create SnapshotCreates the image snapshot for the given VM.
  • Running
  • Stopped

VMware
Install Workload Manager Agent

Install the agent on an Imported VM from the Workload Manager UI. See Virtual Machine 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
  • OpenStack
  • VMware

  • Google

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

On-Demand Actions

You can define On-Demand actions for Workload Manager deployed VMs or imported VMs, and in some cases, even Deployments and Application Profiles.

  • You must explicitly execute these actions from an individual object.

  • Identifies legacy actions that were supported in previous Cloud Remote releases. When using this action type, the action is qualified as On-Demand.

  • The On-Demand Action General Settings section has an additional switch settings to reboot and/or sync VMs after executing the action.

  • See the Defining Actions section below for additional details.

Lifecycle Actions

You can define Lifecycle actions to control the span of resources (cloud regions, applications, services) in which the lifecycle action is made available.

  • You can automatically execute these actions based on a resource’s lifecycle step – you can execute the action on a span of resources which contains the lifecycle action with the possible resources in this type of action are Application Profile, Service, and Cloud Region.

  • When using this action type, the action is qualified as Lifecycle.

  • The Lifecycle Action Resource Mapping section has an additional column for active associations:

    • Whenever a lifecycle action is selected or unselected in an application profile, service, or cloud region, the corresponding active association count is adjusted.

    • On hovering over an active association count, a popover containing the list of resources using that action is displayed.

  • See the Defining Actions section below for additional details.

Once a lifecycle action is defined by a Workload Manager user, permitted users can select that action in one of these resource editor screens:

  • The Properties panel in the application profile's Topology tab: When a lifecycle action is mapped to application profiles, it is visible in the dropdown lists for the Service Initialization and Node Initialization and Clean Up scripts if it is a VM-based action, or in the dropdown lists for External Initialization scripts if it is an external lifecycle action. Lifecycle actions are not available for use as migrate or upgrade scripts.

  • The Add or Edit Service forms: When you map a lifecycle action to a service, it is visible in the dropdown lists for Agent Lifecycle Actions scripts if it is a VM-based action, or External Lifecycle Actions scripts if it is an external action.

  • The External Lifecycle Actions Settings section of the  Regions tab: When an external lifecycle action is mapped to a cloud region, it is visible in the dropdown lists for External Lifecycle Actions scripts for that region.

The lifecycle actions are displayed at the bottom of each dropdown list.

Parameter Definition

Like on-demand actions, lifecycle actions may include one or more parameters specified in the action definition. Each parameter can:

  • Have a default value.

  • Be marked as required in the action editor by toggling the Required switch to On.

  • Be locked by toggling the lock switch to On.

  • Be made invisible by toggling the lock switch to On.

When you select a lifecycle action with parameters from a dropdown list in a resource editor screen, a text label appears to the right of the dropdown field: X PARAMETERS, where X is the number of visible parameters in the lifecycle action. To the right of that label, click Edit to open the parameters editor dialog box where you can specify values for parameters that are both editable and visible.

From the permissions perspective:

  • Users with Deploy permission can deploy an application that is shared with them – even if some of the repositories/lifecycle actions associated with this application are not shared. See Permission ControlApplication Profile Permissions for additional context.

  • Users with a Manage/Modify permission can edit an application that is shared with them – even if some of the repositories/lifecycle actions associated with this application are not shared. See Permission Control Actions Library Permissions for additional context.

The messages that correspond to the execution of lifecycle actions are visible in the Virtual Machines > History tab. See Virtual Machine Management for additional details.

See Deployment Parameters > Granular Control for User-Defined Parameters for additional details on using default values.

See Pre-Defined Parameters > Lifecycle Actions Variables for additional details on using Cloud Remote-defined environment variables.

Error Handling

When defining parameters, you may see one or more of the following errors appear under the action name. Once you fix the problem, the message is dismissed. If the error is not resolved when the user attempts to save the cloud region, service definition, or application profile, an error message is displayed at the top of that form. The following messages are color coded and are issued based on your parameter definition:

  • Warning: If you close the parameters editor dialog box without saving the parameter values, a warning message in the resource editor screen.

  • Error: If you leave any required parameters blank after clicking Save in the dialog box, an error message lists the count of missing parameters. You may see error messages in the following cases:

    • When you add/delete parameters for a lifecycle action even though the lifecycle action is already applied to some resources.

    • When attempting to deploy an application if the deployment uses resources impacted by a change in the lifecycle action. To fix this problem, you must re-save the lifecycle action parameter values, using the parameters editor dialog box, for all resources where this lifecycle action is selected.

Deleting Lifecycle Actions

If you delete a lifecycle action, a confirmation dialog box pops up to warn you with a list of the active associations for the action.

You can only delete a lifecycle action after you remove all active associations – by going to the appropriate resource editor in the %ui and explicitly removing a reference to the action.

If you lose access to a resource that was mapped in the resource mapping section of a lifecycle action, that resource is disabled in the resource mapping section. At this point, the Lifecycle Action Mapping can only be deleted by the action owner.

Lifecycle Actions Mapping

Defining Actions

To define either an On-Demand Action or a Lifecycle Action, click the New Action link in the Actions Library page

Every action that you define has the following areas of interaction:

  • General Settings Section – identifies general data.

  • Resource Mappings Section – identifies where this action should be applied.

  • Action Definition Section – 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.

After configuring the action, you can preview the action to see how the action is presented to the end user.

General Settings Section

This section allows you to define the action properties and identify 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 TypeAction 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.

TypeDescription
Invoke a Web ServiceExecutes 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 Guidance for 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 example:

  • 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 Virtual Machine OS – On a VM with an agent installed. 
    • Externally – On a Docker container that runs in the CloudCenter Suite cluster or Cloud Remote (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. This switch is only available for On-Demand Actions.
  • Sync VM information after action execution – This option allows you to update current VM information (for example, size from the cloud) from Workload Managerso 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. 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
    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.

Chef

Applicable for both Workload Manager deployed VMs and Imported VMs. See Chef Service for additional context.

Puppet

Applicable for both Workload Manager deployed VMs and Imported VMs.  See Puppet Service for additional context.

To run Puppet actions on Workload Manager instance, you must first disable the requiretty setting for that instance in the /etc/sudoers file.

AnsibleApplicable for both Workload Manager deployed VMs and Imported VMs.

Resource 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 Resource Mapping area displays the resources 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 Workload Manager deployed or Imported VMs. The following screenshot shows the Resource 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 Resource Mapping, and each map automatically lists the corresponding fields that you can configure for each map.

TypeResource Mapping (Permitted Resources)Description
Invoke a Web Service

Deployment

  • Deployment Environment: Identify if this action should map to deployments for all Workload Manager supported clouds or for specific clouds. Default = All clouds.
  • Service: Identify if this mapping is intended for all available services or for specific services. Default = All services.
Virtual Machines
  • Application Profile: Identify if this mapping is intended for all application profiles or for specific profiles. Default = All application profiles.
  • Service: Identify if this mapping is intended for all available services or for specific services. Default = All services.
  • Cloud Region: Identify if this mapping is intended for all cloud regions or for specific regions. Default = All cloud regions.
  • Cloud Account: Identify if this mapping is intended for all cloud accounts or for specific accounts. Default = All clouds accounts.
Application Profiles

This option does not contain any configurable fields as the action is applied to all Application Profiles.

  • Command or Script (Default)
  • Invoke Cisco UCS Director Workflow
  • Chef
  • Puppet
  • Ansible

CloudCenter Deployed VMs

  • Application Profile: Identify if this mapping is intended for all application profiles or for specific profiles. Default = All application profiles.
  • Service: Identify if this mapping is intended for all available services or for specific services. Default = All services.
  • Cloud Region: Identify if this mapping is intended for all cloud regions or for specific regions. Default = All cloud regions.
  • Cloud Account: Identify if this mapping is intended for all cloud accounts or for specific accounts. Default = All clouds accounts.

Imported VMs (with agent installed)

  • Cloud Region: Identify if this mapping is intended for all cloud regions or for specific regions. Default = All cloud regions.
  • Cloud Account: Identify if this mapping is intended for all cloud accounts or for specific accounts. Default = All clouds accounts.
  • OS Types: Identify if this mapping is intended for Linux or Windows operating systems. Default = All

Action Definition Section

The following table identifies the available Type along with a brief description and identifies the permitted resources for Resource Mapping.

TypeFieldsNotes
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:
<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.

Username and Password:Credentials required to issue the web service call
HTTP Request Type
  • PUT
  • GET
  • POST
  • DELETE
Content TypeIf the body content should be sent using the JSON or XML format
BodyThe 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:

  • Location: Select from a list of previously-configured repositories as described in the Artifact Repository 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. Workload Managerappends 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 Workload Managerif 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 Virtual Machine 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


    The script invokes the actionSendMessage function and sends status messages to Workload Manager. 
    Locate the cloudcenter-ccm-backend and cloudcenter-cco log files in Kibana to verify that each sent message is being received.

    #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
    }

Executable Command

If you choose to configure this option, provide the command that should be executed as part of the custom action.

Chef

Chef Server

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.

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.

OrganizationThe company or department details. In this example, cliqrtech
EnvironmentThe 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 formatin 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 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.

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.

RoleA role that must exist in the Puppet repository configured above. For example wordpress.
EnvironmentThe 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 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, 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.

PlaybookThe 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 FieldDescription
Display NameRequired. 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, Workload Managerreplaces this field with the passed value in the script.

Help TextProvide 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...

Unable to render {include} The included page could not be found.

Default ValueAssign 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, Workload Managerdisplays 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.

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved