Workload Manager - Action Orchestrator Integration

Overview

Workload Manager 5.0 has built in northbound and southbound integration with Action Orchestrator 5.0:

  • Northbound integration consists of the ability for Action Orchestrator workflows to be initiated as lifecycle workflows or on demand workflows from within Workload Manger.
  • Southbound integration consists of prebuilt activities in Action Orchestrator designed for capturing data from Workload Manager or controlling actions in Workload Manager.

Northbound Integration

Where Action Orchestrator Workflows Appear in Workload Manager

In Action Orchestrator it is possible to define workflows that can be used as lifecycle workflows or on demand workflows within Workload Manager. When properly defined, these workflows appear in the same places in the Workload Manager UI as the corresponding lifecycle actions and on demand actions as summarized in the table below.

Workflow TypeLocations in Workload Manager UI
LifecycleThe Properties panel in the application profile's Topology tab. When the workflow 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 workflow, or in the dropdown lists for External Initialization scripts if it is an external workflow. Workflows are not available for use as migrate or upgrade scripts.

The Add or Edit Service forms. When the workflow is mapped to a service, it is visible in the dropdown lists for Agent Lifecycle Actions scripts if it is a VM-based workflow, or External Lifecycle Actions scripts if it is an external workflow.

The External Lifecycle Actions Settings section of the Regions tab. When an external workflow is mapped to a cloud region, it is visible in the dropdown list for External Lifecycle Actions scripts for that region.
On DemandThe actions dropdown menu for running VMs in the Virtual Machines list page.
The actions dropdown menu for running VMs in the tiers tab of the Job Details page.
The action buttons in the lower right of the VM details page.

The Action Orchestrator workflows are displayed at the bottom of each corresponding dropdown list, or at the bottom of the list of on demand action buttons for on demand workflows.

Creating a Workload Manager Lifecycle or On Demand Workflow

A workflow to be used Workload Manager lifecycle workflow or on demand workflow can be created in one of two ways: 

  • Automated method: The workflow is created by clicking an "add" menu selection from one of the dropdown lists in the Workload Manger UI. In this case, some key initial steps in creating the workflow are performed automatically.
  • Manual method: The workflow is created from scratch starting in the Action Orchestrator module.

Both methods assume you are using Workload Manager 5.0.1 or later and Action Orchestrator 5.0.1 or later. The automated method is preferred, but the manual method is explained first to illustrate what happens behind the scene with the automated method.

Manual Method

  1. From Action Orchestrator home screen, open the workflow editor as explained in Creating a Basic Workflow.
  2. From the workflow editor, find the Get Workload Manager Context activity in the Activities panel on the left, then click and drag it to the canvas. This is the key activity that drives the integration between Workload Manager and Action Orchestrator.
  3. Before selecting the Get Workload Manager Context activity in your new workflow, the Properties panel on the right corresponds to the new workflow as a whole. Enter the name of the workflow in the display name field in the Properties panel. 
  4. Scroll the Properties panel down to the Variables section to create a new variable using the Add Variable button. Name the variable CC_RUN_ID and set it as type String and scope Input. This is needed In order to link the workflow with the deployment or VM associated with the workflow. The Get Workload Manager Context activity will automatically set this variable to the Job ID if it is used for a lifecycle workflow, or to the VM ID if it is used for an on demand workflow. 

  5. Optional. If this workflow needs to run a command or script on a VM, you also need to add a second variable of type String and scope Input, and name it NODE_ID.  This is used by the Execute Action on Virtual Machine atomic workflow activity. You will use this atomic workflow activity when you want to run a command or script on a VM (see below). If you do not plan to use this workflow to run a script or command on a VM, the NODE_ID input field is not required.

  6. Select the Get Workload Manager Context activity that you dragged to the canvas. This causes the Properties panel to correspond to this activity. In the Properties panel, set the Job ID field to the CC_RUN_ID variable by clicking the Variable Reference (puzzle piece) icon and then selecting Workflow > Input > CC_RUN_ID and then Save.  This completes the linking between the new workflow and the VM or deployment from where the workflow is to be called.
  7. Define the type and scope of the workflow. Click the add button under the Workload Manager Configuration section in the Properties panel. (See Get Workload Manager Context for details). This brings up dialog boxes comparable to those used in specifying the type and scope of Actions Library actions. Through these dialog boxes specify:
    1. Workflow Availability: Lifecycle or On Demand.
    2. Execute Action: On Virtual Machine OS or External.
    3. Resource mappings: Select the appropriate resources in a fashion similar to mapping Actions Library actions to resources. 
  8. Add additional activities to the workflow appropriate to your use case. In particular, If you want to execute a command or script on a VM, you would add the Execute Action on Virtual Machine atomic workflow activity to your workflow. See Other Useful Activities for Building Lifecycle and On Demand Workflows below for more details.

Automated Method

From within the Workload Manager UI, where ever lifecycle actions or on demand actions are displayed (see previous table), an Add workflow menu selection or button will appear. Clicking Add will cause a new workflow to be generated in Action Orchestrator with steps 2 through 6 from the manual method (above) to be performed automatically, and a new tab to be opened in your browser that points to the newly created workflow in the workflow editor screen.

This newly created workflow includes an automatically generated workflow name per the following convention: if the workflow is created from the context of adding an on demand action workflow, or from adding a lifecycle action from a service, the name of the workflow is of the form: WM_AO_OOB_WF_<random_6_char_string>; if the workflow is created from the context of adding a lifecycle action workflow to an application profile, the name of the workflow is of the form: <app_profile_name>_<random_6_char_string>. You can change the name as you see fit.

The newly created workflow also includes the partial creation of the Workload Manager Configuration settings. If the workflow is created from the context of adding an on demand workflow, the  workflow type is set to On Demand. If the workflow is created from the context of adding a lifecycle workflow, the workflow type is set to Lifecycle. 

The automated method requires that you first import the WM_CREATE_WF workflow into your user account from the public Cisco Action Orchestrator repository. This is included in the instructions below.

The steps to create a new workflow from within Workload Manager are as follows:

  1. If this is the first time you are attempting to create workflows from within Workload Manager, you must first import the WM_CREATE_WF workflow into your user account from the public Cisco Action Orchestrator repository as described in the following steps:
    1. From within Action Orchestrator, create a Git repository integration with the public Cisco Action Orchestrator repository. This requires that you have the tenant admin role. If another tenant admin in your tenant has created this repository link already, get the name of that integration and skip to step b, below.
      1. In the Action Orchestrator UI, navigate to Admin > Git Repositories and click New Git Repository.
      2. In the New Git Repository dialog box, ensure the following fields are set as specified:
        1. No Account Keys = TRUE
        2. Rest API repository = api.github.com/repos/cisco/ActionOrchestratorContent 
        3. Branch = master
        4. Code Path =  /workflow-examples
      3. Give the Git repository integration a memorable name, eg, CiscoPublic, and save it.
    2. Import the WM_CREATE_WF workflow action:
      1. Navigate to Main Menu > Workflows and click Import in the upper right.
      2. In the Import Workflow dialog box, ensure the following fields are set as specified:
        1. Imported From = Git
        2. Git Repository = The name the Git repository integration created in step 1a, above.
        3. Filename = CloudCenterSuite-WMCreateWF
        4. Git Version = The latest version of the workflow available in the dropdown
        5. Import as a new workflow (clone) checkbox is unchecked (Important!)
      3. Click the Import button in the lower right of the dialog box. A new VM_CREATE_WF workflow should appear in your list of workflows in the My Workflows tab.
  2. Set the ao.workflow.oobuniqueName property In the cloudcenter-manager configmap:
    1. Install kubectl on your local computer, download the CloudCenter Suite provided Kubeconfig file, then move the kubeconfig file to the directory specified in the $kubeconfig environmental variable. This allows you to connect to the CloudCenter Suite cluster with kubectl from you computer.
    2. From the command prompt of your computer, use kubectl to ensure your CloudCenter Suite instance has a configmap for the cloudcenter-manager pod:

      kubectl get configmaps -n cisco
    3. Once confirmed, use kubectl to launch your default editor to edit the cloudcenter-manager configmap:

      kubectl edit configmaps cloudcenter-manager -n cisco

      Your editor should display the configmap in edit mode to allow you to modify it:

      apiVersion: v1
      data:
        external.hosts: "hostA:portA"
      kind: ConfigMap
      metadata:
        creationTimestamp: 2018-12-19T15:31:04Z
        labels:
          app: cloudcenter-ccm-backend-5.0.0
          chart: cloudcenter-ccm-backend-5.0.0
          heritage: Tiller
          purpose: configuration
          release: workload-manager
        name: cloudcenter-manager
        namespace: cisco
        resourceVersion: "18309514"
        selfLink: /api/v1/namespaces/cisco/configmaps/cloudcenter-manager
        uid: 18c30efe-03a3-11e9-bd86-42010a80004a
    4. Using your editor: 
      1. Create a property called ao.workflow.oobuniqueName and set the value to definition_workflow_0167MFDE4LAAQ5SsquNIWqY1x3Tmxankwzt.  Insert this right after the external.hosts property.

        ao.workflow.oobuniqueName: definition_workflow_0167MFDE4LAAQ5SsquNIWqY1x3Tmxankwzt
      2. If the ao.workflow.oobuniqueName property already exists, make sure it is set to the value listed above.
      3. Save the file and exit your editor.
      4. Saving the configmap automatically causes the cloudcenter-manager service to restart. Wait about five minutes for the restart to fully complete.
  3. In the Workload Manager UI, from any location where it is possible to select a lifecycle action or an on demand action (see previous table), scroll down to the end of the dropdown menu, or list of buttons, and select Add. This will open a new tab and eventually display the newly created workflow in the Action Orchestrator workflow editor.

  4. In the Action Orchestrator workflow editor canvas, click the Get Workload Manager Context activity to cause its properties to be displayed in the Properties panel, scroll down to the Workload Manager Configuration section, and click the edit button. Use the dialog boxes to specify:
    1. Workflow execution location: externally or on the VM.
    2. Resource mappings: select the appropriate resources in a fashion similar to mapping Actions Library actions to resources. 
  5. Add additional activities to the workflow appropriate to your use case. In particular, If you want to execute a command or script on a VM, you would add the Execute Action on Virtual Machine atomic workflow activity to your workflow. See Other Useful Activities for Building Lifecycle and On Demand Workflows below for more details. 

Other Useful Activities for Building Lifecycle and On Demand Workflows

Execute Action on Virtual Machine atomic workflow activity

The Execute Action on Virtual Machine activity is required if you want your workflow to execute a command or script on a VM. This activity should only be used in workflows where the Get Workload Manager Context is the first activity. To use this activity in a workflow, perform these steps:

  1. Check to see if this atomic workflow is visible in the activities panel on the left side of the workflow editor screen. If yes, skip to step 2. If no, it must be imported by a user in your tenant with tenant admin privileges using these steps:
    1. If you already have a Git repository integration with the /atomic-actions code path in the public Cisco Action Orchestrator repository, skip to step b. Otherwise, create one now using the following procedure.
      1. In the Action Orchestrator UI, navigate to Admin > Git Repositories and click New Git Repository.
      2. In the New Git Repository dialog box, ensure the following fields are set as specified:
        1. No Account Keys = TRUE
        2. Rest API repository = api.github.com/repos/cisco/ActionOrchestratorContent 
        3. Branch = master
        4. Code Path =  /atomic-actions
      3. Give the Git repository integration a memorable name, eg, CiscoPublicAtomic, and save it.
    2. Import the Execute Action on Virtual Machine workflow action:
      1. Navigate to Main Menu > Workflows, select the  and click Import in the upper right.
      2. In the Import Workflow dialog box, ensure the following fields are set as specified:
        1. Imported From = Git
        2. Git Repository = The name the Git repository integration created in the step a, above.
        3. Filename = CloudCenterSuite-ExecuteActionOnVM
        4. Git Version = The latest version of the workflow available in the dropdown
      3. Click the Import button in the lower right of the dialog box. A new Execute Action on Virtual Machine atomic workflow should appear in the list of workflows in the Atomic Workflows tab.
  2. In the Actions Orchestrator workflow editor screen, drag and drop this atomic workflow from the activities panel to the canvas at a position after the Get Workload Manager Context activity.
  3. Select this newly added activity to cause the properties panel to refer to this activity. From the Properties panel, populate the following required input fields:
    1. Get CloudCenter Context Response: Click the variable reference icon and select Activities > Get Workload Manager Context > Response Body and then Save.
    2. Action Type: Click the variable reference icon and select Activities > Get Workload Manager Context > Action Type and then Save.
    3. NODE_ID: If this workflow is a lifecycle workflow, click the variable reference icon and select Workflow > Input > NODE_ID and then Save. Otherwise, this field can be left at its default value which is null.
    4. Script: Enter the path of the script or command on the VM that is to be executed. The script may be a shell script for Linux VMs or a PowerShell script for Windows VMs.

JSONPath Query atomic workflow activity

The JSONPath Query activity lets you parse the response body of a previous activity in the workflow from which it is called.  The response body of the Get Workload Manager Context is either a job details API call response body (for lifecycle workflows) or a VM details API call response body (for on demand workflows); therefore, the JSONPath Query activity can be used to extract specific fields related to the job or VM so that they can be used later in the workflow.  For example, to parse the owner email address from the Get Workload Manager Context response body, follow the steps below.

  1. Drag and drop activity from the activities panel to the canvas at a position after the Get Workload Manager Context action.
  2. Select this newly added activity to cause the Properties panel to refer to this activity.  In the Properties panel, set the Source JSON to Query field to the Get Workload Manager Context response body by clicking the variable reference icon and then selecting Activities > Get Workload Manager Context > Response Body and then Save.  
  3. Under the JSONpath Queries label, click the Add button. This reveals three fields:
    1. JSONpath Query: Enter the field name as specified in the response body output. In the case of the owner email address, enter: "$.ownerEmailAddress".
    2. Property Name: Enter a user friendly field name.
    3. Property Type: Select a field type from the dropdown menu. In the case of the owner email address, select String.
  4. Optional: To extract addition fields from the response body, repeat the the previous step as necessary.

Generic CCS API Request atomic workflow activity

The Generic CCS API Request activity lets you execute a CloudCenter Suite API call within your workflow. 

  1. Drag and drop activity from the activities panel to the canvas at the appropriate position of your workflow.
  2. Select this newly added activity to cause the properties panel to refer to this activity.  In the Properties panel, under the CCS API Request label, enter values for these three fields:
    1. Relative URL: Enter the portion of the API call that comes after <address>:<port>.
    2. Method: Enter GET, POST, PUT or DELETE as appropriate.
    3. Request Body: Enter the JSON request body if required.

      The request body can include any of the variables available within the workflow: position your cursor at the appropriate position of the request body, click the variable reference icon, and then use the variable reference browser to select the appropriate variable.

Southbound Integration

Action Orchestrator has a set of activities under the CloudCenter Suite adapter for performing actions on various components within the CloudCenter Suite. Some of these activities are unique to Cost Optimizer, some are unique to Workload Manager, one is shared between Workload Manager and Cost Optimizer, and one is common to all modules as summarized below.

Workload Manager Specific Activities

  • Get Workload Manager Context. See also Creating a Workload Manager Lifecycle or On Demand Action Workflow, above.
  • Manage Deployment Environment. With this activity, you can add a cloud account to one or more regions within a deployment environment. You must specify the deployment environment and regions already associated with the deployment environment. You must specify the cloud account using its CloudCenter Suite account ID. When specifying regions, you must ensure that all regions you select are associated with the same cloud type as the cloud account you are adding. 
  • Execute Action on Virtual Machine.  See Other Useful Activities for Building Lifecycle and On Demand Workflows, above.

Workload Manager / Cost Optimizer Shared Activity

  • Add Cloud Account. Use this activity to add a cloud account created within the cloud provider to the CloudCenter Suite.

CloudCenter Suite Common Activity

  • Generic CCS API Request.  See also Other Useful Activities for Building Lifecycle and On Demand Workflows, above.




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