// removed jquery ui css and js

Configure a Cisco UCSD Cloud

The CloudCenter platform provides Cisco Unified Computing Systems Director (UCSD) integration that enables you to invoke UCSD callout workflows. Users can drag and drop the Cisco UCSD service into the CloudCenter Topology Modeler and create a topology with single or multiple UCSD callouts. This allows enterprises to create a mixed topology of applications using UCSD callouts and provides the following benefits:

  • Enterprises can use CloudCenter for governance as well as workflow management.  

  • SysAdmins can use UCSD to provision physical storage.

Limitations

Be aware of the following limitations if you decide to use this integration:

  • The CloudCenter platform does not support HA environments for UCSD workflows.

  • See Phase 1: Prepare Infrastructure for release compatibility details.

  • This implementation of the UCSD integration allows you to provision your storage setup on network appliances (tested and verified for the CloudCenter platform).

    UCSD currently allows VM provisioning.

  • This feature has been tested and implemented for select customers.

  • This version only supports the integration that is explicitly mentioned in this page.

  • Worker1 appliances are not required for this integration.

  • CCM and CCO appliances are not available for this integration.

  • When you create an External Initialization Script (see External Service) for a cloud region and launch a UCSD workflow from the CCM, the workflow is executed but the region-level External Initialization Script is not executed. This is because the External Initialization Script (PreVM init) is generally executed before a VM is launched and there is no VM being launched in UCSD.

  • Even if you have multiple UCSD accounts in CloudCenter when modeling an application, the CloudCenter platform does not allow you to select a specific region of UCSD. Essentially, you can only have one UCSD account for each CloudCenter platform.

Integration Requirements

To integrate with Cisco UCSD, the CloudCenter SysAdmin must adhere to the following requirements:

  • Administrator ability to access to the Cisco UCSD account and environment.

    If you intend to integrate UCSD in your enterprise, the CloudCenter platform requires access to the UCSD environment to provide end-to-end deployment.

  • Knowledge of the list of UCSD workflows to be called by the CloudCenter platform.

    The CloudCenter platform abstracts the orchestration process to use the callout flows exposed by UCSD. The CloudCenter platform merely uses exposed UCSD parameters for cloud governance and management purposes.

  • Each Cisco UCSD instance must be associated with a CCO before you Model an Application.

  • Currently, one CloudCenter platform supports one UCSD instance.

  • Each CloudCenter UCSD implementation requires an associated physical image entry in the CloudCenter platform (this is a dummy placeholder – even if a logical Image is not used).

UCSD Workflow Support

UCSD has the concept of workflows. These workflows differ between enterprises and deployments. An example of such a workflow is when you provision storage using the UCSD integration, CloudCenter currently calls the following workflows:

  • Create a new storage space or VM (generally referred to as resource)

  • Validate the existence of a storage space

  • Update an existing storage space

  • Delete a storage space

  • Retrieve information about a storage space

UCSD Workflow Requirements from CloudCenter Perspective

The CloudCenter platform requires the following UCSD IDs:

  • Service Request ID: This ID is generated by the UCSD workflow. The CloudCenter platform uses this ID.

  • Resource ID: In the Deployment workflow when you create a new storage space or VM, the CloudCenter platform expects to receive the resource ID (the ID of the provisioned resource) of the UCSD workflow as an output parameter.

The CloudCenter termination workflow (that a UCSD user sets up) should typically use this Resource ID to refer to the originally provisioned entity and remove that entity as required.

For example:

  • If your workflow needs to provision a storage system, your workflow should return a Storage ID as the Resource ID.

  • If your workflow needs to launch a VM, it could return the VM ID as the Resource ID.

The following is a basic sample script to return a Resource ID from a UCSD workflow task.

//// return value for Cisco Cloud Center
//
var srid=ctxt.getSrId();
logger.addInfo("SR ID: " + srid);
json_output="{"resourceId":"" + srid + ""}";
logger.addInfo("json_output: " + json_output);


output.JSON_OUTPUT=json_output;

Configure UCSD as a Custom Service

The current UCSD workflows are specific to the creation and maintenance of additional storage work spaces for enterprises. As UCSD is associated with one CCO, each time you access information about the storage space, the CCO retrieves the permitted UCSD workflows.

To configure, define, and use UCSD as a custom service, follow this process:

  1. Access the CCM UI > Admin > Clouds > Add Cloud in the CCM UI main menu.

  2. Select the Cisco UCSD option, provide a Name and Description for this cloud, and click Save.

  3. Edit or create the instance type using the following details. See Manage Instance Types for additional context.

  4. Edit or create the cloud mapping using the following details. See Map Images for additional context.

  5. Add UCSD as the deployment environment. See Deployment Environments.

  6. Edit the Cisco UCSD service to define the allowed UCSD workflow parameters. See Custom Service Definition.

  7. Model a new N-tier application to use the Cisco UCSD service. See Model an Application for additional context.


  8. Save and deploy the UCSD application.
         

    

You have now configured and launched UCSD as a custom service.

Sample UCSD Workflows

These workflow are merely samples – Be aware that the workflow will differ based on your local environment!

This is a sample of a custom task that returns the instance ID.

This is a sample of the global output:

This is the sample of a custom task mapping within the workflow for the Service Request ID to be returned to the CloudCenter platform:

This is the sample of a Resource ID being returned to the CloudCenter platform – When talking to UCSD, the CloudCenter platform requires the last task to report a Resource ID back to the CloudCenter platform. This resource ID can be the UCSD Service Request ID. A custom task must provide this function.

This is a sample termination workflow:


The same sample workflow from the CloudCenter perspective:

Cisco CloudCenter expects the termination workflow to have that input label (the Resource ID) as it injects the ID that was returned from the original JSON output.

This is a sample workflow input:

This is a sample termination and rollback in UCSD:

Return to: Configure Cloud(s)

  • No labels
© 2017 Cisco Systems