CloudCenter Integration Fundamentals - UCS Director

[tuanngu4]

Summary:

The goal of this document is to explain the basic capabilities delivered by CloudCenter's integration with UCS Director. As of the time of this writing, CloudCenter is compatible with UCSD 5.2.x, 5.3.x, 5.4.x, 5.5.x and 6.0. Although there are similarities between the two management platforms (all of which will not be itemized herein) they can coexist in the same private cloud environment and can complement one another without relying on the other to provide service.

The ultimate goal is to present the cloud consumer with a unified self-service portal from which to consume the assets and services managed by UCSD. Each product allows the service architect to model their respective service offerings independently, with UCSD offering the Workflow Designer and CloudCenter offering the Topology Modeler.

Services in the form of workflows in UCSD would continue to be designed by administrators who are typically intimately aware of the characteristics of the infrastructure elements under UCSD's management. These workflows can then be incorporated into CloudCenter's native application profiles as a service element from the out-of-box content library. The UCSD service can be used as a standalone service in an application profile or in conjunction with various other application related services (e.g. HAProxy, Apache, Tomcat, MySQL).

Set up:

There is already an outstanding contribution to the community by Orf Gelbrich detailing the configuration requirements of the integration (DOC-67673). This walkthrough is applicable to CloudCenter versions pre-dating 4.7. Starting with 4.7, the process to integrate UCSD will be more streamlined for the cloud admin and the steps to access the database and change respective database entries will become unnecessary. To summarize the document, these are the instructions as stated there:

1. Deploy the CCO and AMQ
   • If deploying the CCO from an OVA, the /usr/local/osmosix/etc/cloud and /usr/local/osmosix/etc/profile.properties files need to contain the the value "CiscoUCSD"
   • If deploying the CCO from the core_installer.bin file, the syntax is ./core_installer.bin centos7 ciscoucsd cco(assuming CentOS 7.x as the base OS for the appliance)
     • NOTE: UCSD is considered a cloud target in this context, much like AWS or VMware, so the same requirement applies - the CCO must be connected firstly to the AMQ so that it will be successfully registered to the CCM. No application nodes will connect to the AMQ when the CCO is used for UCSD integration.
   • If deploying the AMQ from an OVA, remove the /usr/local/osmosix/etc/.RABBITINSTALLED file.
   • If deploying the AMQ from the core_installer, the syntax is ./core_installer.bin centos7 vmware rabbit(assuming CentOS 7.x as the base OS for the appliance and VMware as the underlying private cloud environment)
     • NOTE: VMware is not required and is used to provide a sample of the requisite syntax.
2. Expose the Image definition named "Callout Workflow" (this step is applies to versions pre-dating 4.7 and is necessary because the Image definition was not exposed by default). Log on to the console of the CCM and follow the these steps:
   • Stop Tomcat: /etc/init.d/tomcat stop
   • pre v4.5.x, use mysql -uosmosix -p osmosixdb (use password "osmosix")
     • select * from IMAGES where name='Callout Workflow';
     • update IMAGES set deleted=0 and privateImg=TRUE where name='Callout Workflow';
     • quit;
   • v4.6.x, use psql -U cliqr -d cliqrdb (use password "cliqr")
     • select * from IMAGES where name='Callout Workflow';
     • update IMAGES set private_img=true, deleted=false where name='Callout Workflow';
     • \q
   • Start Tomcat: /etc/init.d/tomcat start
3. Add Cisco UCSD as a cloud into the CCM cloud administration page
   • Enter the IP address of UCSD, the API key of the intended UCSD user and the main folder in which the workflows are stored
   • Create a cloud region and register the CCO as the intended orchestrator of that region
     • The configuration of the IP for the Remote Desktop Gateway is inconsequential here, since there are no application nodes launched in the UCSD region - Guacamole will not be required to connect to any nodes
   • Add an Instance Type for the region
   • Add a mapping to the Image definition named Callout Workflow
     • NOTE: Because UCSD gets onboarded as a cloud, the normal conventions of a cloud region apply. I stated earlier that no nodes are launched in this region, but both Instance Type and Image mapping must contain values so that the requirements of te deployment process can be satisfied. Therefore, the Instance Type and Image mapping are more or less "dummy" values
4. For each workflow in UCSD that the admin wishes to execute via a CloudCenter application profile, the custom "CliQr_Wait" task must be added as the last task in the sequence of tasks (this is accomplished via the Workflow Designer
   • The Input Value called Param1 (type Generic Text Input) should be created (the name is inconsequential)
   • The Output Value called JSON_OUTPUT (type Generic Text Input) should be created(here the name is also inconsequential but does need to match the value referenced by the script in the custom "CliQr_Wait" task
5. Create the application profile in CloudCenter and add the Deployment, Detail, Reconfiguration and Termination workflows
   • The Deployment workflow typically contains various user input which are native to UCSD and which can be exposed to the user during deployment submission time
     • Here the options are LaunchTimeInput, InstanceType and Application
   • The Termination workflow should specifically be the RollBackSRv1
     • Here the resourceId value must be set to the "Application" option and must contain the text "resourceId"

Explanations:

There are some clarifications needed to help administrators troubleshoot the integration between CloudCenter and UCSD should the need arise. The following is not an exhaustive list, so please leave feedback/questions/comments as appropriate:

1. The custom "CliQr_Wait" task exists to provide an information exchange between CloudCenter and UCSD. When CloudCenter makes a request to UCSD to execute a workflow, it does so while impersonating the user whose API key is specified in the cloud account configuration. Once UCSD completes the sequence of tasks, the very last thing in the workflow is the custom task, which takes the original Service Request ID (a value native to UCSD) and sends it via the JSON_OUTPUT value to CloudCenter. CloudCenter stores this value as the "resourceId," which it displays as the node ID on the Deployment Status page for the job. An administrator can associate the node ID on the status page in CloudCenter to the UCSD Service Request ID in the Organizations page of UCSD
2. Currently there are 4 workflow types in the UCSD service - Deployment, Details, Reconfiguration and Termination. These exist because CloudCenter offers a full lifecycle framework to the application profiles and the resultant application deployments. Most UCSD workflows create infrastructure objects that do not behave like applications and therefore do not require as extensive a lifecycle treatment. The 2 most critical are the Deployment and Termination workflows
3. There are 3 discrete options presented to the CloudCenter user related to the input values of a UCSD workflow:
   • LaunchTimeInput - this option displays the value to the CloudCenter user during the deployment request and passes that value specified by the user during the deployment from CloudCenter to UCSD
   • InstanceType - this option was created specifically to meet the requirements of a customer use case and essentially captures the volume size of the Instance Type selected by the user during the deployment request; with this option, the user sets the value by selecting the Instance Type and not by supplying a value in a text box
   • Application - this option does not display the input value to the user during the deployment request and assumes that there is an "admin provided" value already specified in the UCSD workflow.
     • NOTE: Both LaunchTimeInput and Application options allow the CloudCenter user to interact with the system in a similar way to UCSD. Though the process of allowing the value to be set in the CloudCenter UI and passing those values to UCSD for processing and fulfilling the requisite tasks in a UCSD workflow, CloudCenter does not record the values in its database.