Workflow with Cisco UCS Director

In this post, I will go through the process of creating a standard user request to deploy a virtual machine through Workflow (as opposed to the method described in the self -service post using Cisco UCS Director ). Below we will familiarize ourselves with the concept of Workflow, see the interface of the Workflow editor and create our first Task.

Workflow, as described in the Cisco UCS Director Orchestration Guide, consists of two or more tasks that share a common execution logic. Workflow determines the order in which tasks are performed. In other words, Workflow is a set of interconnected elements that perform a specific set of actions in accordance with a given logic. Moreover, the logic can be determined by the system administrator.

Cisco USCD provides an administrator with two key elements for creating and working with Workflow:

• Workflow UI designer (GUI for editing, see image below);
• A set of standard (typical) tasks (over 400).

The interface of Workflow Designer is very simple, I would even say primitive. That I personally really like, because there are no extra elements that usually overload the working area of ​​the screen.

On the left is the “Available Task” area, where all built-in typical tasks are grouped. There is also a search bar. The central part of the window is occupied by the workspace where the Task s are located. At the top there are several buttons that allow you to perform a number of actions, including launching the created Workflow directly from the editor, which is very useful for debugging.

Typical Tasks

A typical task is a predefined set of atomic actions grouped in one object. You can submit a set of certain resources to the input of such a task (including through previously defined policies). At the output, the task can transmit certain information for another task (for example, the parameters of the created virtual machine). Later in the post I will use two typical tasks to create a Workflow that will determine the user's actions for creating a virtual machine.

Taskes communicate with each other in the workspace. For each task, you can determine which task will be executed further in case of its successful execution, as well as in case of unsuccessful. To do this, you can use the beautiful red and green arrows (JavaScript steers :-)). Thus, it is possible to determine the branching logic of the task, and a fairly clear picture is obtained.

UCSD allows you to display a complete list of all tasks with a detailed description of each of them and a sample code. To do this, in the menu Policies -> Orchestration -> Workflow, select the Task Library command and say Submit. For example, the description of the standard task "VMWare Host Power Action" is shown below.



In addition, typical tasks perform the functions of collecting statistics and discovery of objects of physical and virtual infrastructure, the so-called "Collect Inventory Task".

Workflow

In order to get to the Workflow section, go to the Policies -> Orchestration -> Workflow menu. All existing Workflows are grouped into directories. A set of standard Workflows is already included in the UCSD package, for example, in the System directory you can see the following:

• VMWare OVF Deployment;
• VMWare VM Provision;
• VMware Clone VM.

With Workflow, as with other UCSD objects, you can perform a number of standard operations, such as:

• Editing;
• Escort / import and export as a template;
• Cloning;
• Schedule their implementation using a sheduler;
• Lock or unlock.

Virtual Machine Provisioning with Workflow

Enough of the theory, let's create our first Workflow, with which users can deploy a virtual machine to a self-service portal. To do this, go to the menu Policies -> Orchestration -> Workflows and click on the Add Workflow button. A window appears in which you must specify the unique name of Workflow - my_first_wf, the execution context (in our case Any) and select the directory in which our Workflow will be saved - IT-GRAD_TEST. Click Next. Go to the "Add User Inputs" window. Here we can determine what data Workflow will request from the user at the beginning of its execution. In essence, “Workflow User Inputs” is a typical task that will be executed during the work of our Workflow. We will not create any additional tasks yet.











Click Submit. Get the new Workflow in the IT-GRAD_TEST directory. If you carefully look at its status, you can see that there is a note Validation Status = Failed. This is due to the fact that we have not yet identified any tasks.

Move on. Editing our WF. You can enter the editor either by double-clicking on the Workflow, or selecting it from the list to give the Edit Workflow command, or to give the Workflow Designer command.

Those who will somehow work with the UCSD interface will quickly notice that often the same operation can be performed in several ways.

We open WF Designer and define a set of tasks that must be performed when creating a virtual machine. I’ll clarify right away that I will use typical tasks.





First of all, we need to determine the composition of the resources created by the VM. This can be done using the standard task - Resource Allocation. To do this, we type allocate in the search bar and at the very bottom we see the task we need. With the mouse we drag the task into the working field. The task settings window appears, where we can determine the task name. The Task Details list defines attributes whose values ​​will be passed to the next task after the current one is completed. The list of these fields is important, since we will need to define all of them (or part of them) in our next task. Click Next













In the window that appears, we can connect the User Input and Task Input Attributes. In Russian, this means that we can set certain values ​​for the attributes of the task, which the user will either enter or they will be transferred from the previous task after its execution. For example, we can explicitly indicate exactly how we will deploy the VM Deployment Options virtual machine - based on the Template or based on an existing virtual machine. If we explicitly determine how the virtual machine is deployed, the user will not have to set it when prompted on the self-service portal (he simply will not have a choice). You also need to understand that those task attributes that are marked as Mandatory, UCSD will need to be defined anyway.

We leave everything unchanged and click Next



In the Task Inputs window, we see that we need to determine the VM deployment options, the directory and vDC in which the created VM will be located. Set the desired values ​​and click on Submit. As you can see, our new task is automatically defined as a starting one and has two options for completion. All subsequent tasks we will need to include in our Workflow manually. Now we need to add the next task that will deploy the virtual machine. It is called VM provision. Interestingly, this task is located in the Cloupia Tasks directory, unlike the previous one. We transfer it to the work field. Task name is left unchanged. Please note that the VM Provision task outputs only the value of the VM_ID attribute. Click Next.

















I will try to describe the procedure for setting User Inputs for this task in more detail. Remember, I mentioned in the description of the Resource Allocation task that it outputs a set of attribute values ​​that can be passed to the next task? Now we will do it. For example, we map the Select Host task attribute to the passed value from the Resource Allocation task "ALLOCATED_HOST". We will do the same for task attributes from “Select Datastore” to “Select Additional IPv6 Address”.

It should look something like this:



The attributes for the last three task “Number of vCPUs”, “Memory”, “Disk”, which respectively determine the number of virtual processors, the amount of VM memory and the size of the VM disk, can be left unchanged. You can determine them in the next step. And you can define them through separate User Inputs Workflow. I will demonstrate how this can be done using the Disk Size Selector task.

To determine its attribute, click on the Manage Workflow User Inputs button at the top of the window and get to the Workflow User Inputs definition window. Press “+”. Set the label and click on Select . Drive “disk” in the search bar and select the Disk Size Selector task.















Further we can set restrictions for the value of attributes of a typical task. To do this, click Admin Input Filter and determine the allowed disk size through a regular expression. In our case, I want to limit the user’s choice to 20 GB and 60 GB disks. For a detailed description of filter syntax, see the Filter Criteria Syntax for Admin Input Filter section of the Cisco UCS Director Orchestration Guide. Click Submit and again get into the User Input Mapping window. To drag Disk, select the Workflow User Inputs “Disk size” that we created. This completes the User Input Mapping settings. Click Next











Note that we again need to specify the VM Deployment Type, select the directory, and vDC. In addition, we can set a new name for the virtual machine and redefine the amount of vCPU and memory.

Click Submit.

Now we need to link the created task with other elements of our Workflow. To do this, we need to hover over the created task and display a drop-down list for the green field On success. In the drop-down list, select Complete (success). For Task Resourse Allocation, specify VMProvosoin_175 in the same list. As a result, we get the following: And do not forget to indicate what to do with VM Provision in case of failure. That's all. For accuracy, you can click on the Validate Workflow button and, if no errors appear, click Close.

Create a new directory

As I already wrote in the post “Self-service with the help of Cisco UCS Director: how to give users the opportunity to create virtual servers on their own”, in order for users to create a virtual machine on the self-service portal, we need a directory. A directory of type Standard was created in the mentioned post, now we will create a directory of type Advanced.

To do this, go to the menu Policies -> Catalogs and give the Add command. Let's set the name of the new directory CentOS_vm_wf, type Advanced and select our favorite group Cust1. Click Next.





Compared to the directory in the self-service using the Cisco UCS Director: How to Give Users the opportunity to create virtual servers on their own, post, there are very few settings for the Advanced type directory. In the next window, we will indicate our new Workflow and that’s all. To do this, click on the Select button. Check the box opposite our Workflow, click Select again, then Next and Submit. Directory created.

Virtual Machine Request

We log in to the self-service portal as a user in the Cust1 group and start the process of creating a new VM based on our new catalog. Remember that we set the values ​​for such parameters as, for example, the number of vCPUs or the amount of memory at the stage of creating Workflow, and the user was given the choice of VM disk size. We set the size we need and click Next, then Submit. Let's look at the progress of our request, as we see the machine is already deploying :-) That's all. I tried to tell about the most important and interesting Cisco UCSD functionality as simple and clear as possible.