Ok we are finally getting somewhere now with this series! So far we have downloaded, installed, and configured our vCO appliance. As well, we have registered our vCO instance with both vCenter and our SSO instance. This post will take us through verifying and testing our installation by creating and setting up a small workflow that we can then assign to some inventory objects inside of vCenter. This will allow us to perform that right-click magic in the Web Client and see for ourselves some of the awesome integration vCO and vCenter have.
With that said let’s get started on our test workflow. To do so you will need one of clients available to vCO. As you can see in the screenshot vCO provides you with a couple of options to start the client; one simply runs a java applet and the other let’s you install a client directly on your machine – whichever method you chose you end up sitting at the exact same login screen. Once you get there you should be able to simply input your vCO IP as the Host name and your proper credentials.
OK! So here we are, the vCO workflow development interface. Look a little foreign to you? No worries, it did to me as well. Actually, it still kind of does, this is just “My First” vCO workflow remember! So for the most part I’ve only really explored the workflow icon (shown below). The others are simply Home (home), Scheduler (Allows scheduling of workflows), Policies ( Allows other plugins to trigger the kick off of workflows), and Inventory (You will see your vCenter inventory objects here). For now, we need the Workflows section active.
So after you expand the Library tree you should see several folders by default. These folders contain all of the workflows that vCO is aware of. Obviously we can add more by creating our own or installing plug-ins (covered in Part 4). For now we will just create one of our own workflows. Before going to crazy I always like to create my own folder for things like this. I get a bit nit-picky about file management sometimes 🙂 To do so is pretty simple – Right Click Library -> Add New Folder and give it a name!
So now it’s time to create our workflow – Again Right-Click the folder you want to store it in and Select New Workflow and name it. At this point a new window, the workflow editor will open up. There is a lot of information and tabs here and to be honest I’m not going to explain what they all are. Partly because it would make this post much too long, but mostly because I don’t have a grasp on what they all are :). The main tab that we will be working in is called Schema. This is where we setup all of the flow elements inside our workflow. Once there you will see our main window is displaying the flow of everything, and the left hand side is showing all of the workflows that we can add to our workflow. The one I am interested in is ‘Reboot host’ As you can see you can browse through the tree of All Workflows to get to it or you can simply use the filter box at the top to search for specific workflows. Once you find it you simply add it to your workflow by dragging it into your flow window.
After doing so you will see a black bar along the top of the screen asking about the activities parameters. Something to know – workflows have inputs and outputs – these are pretty self explanatory. When we created the workflow initially it had inputs and output, and then when we dragged the Reboot Host workflow into ours it also had inputs and outputs. So what this is asking is if we would like to move the Reboot Hosts inputs into our workflows inputs. In this case this is something we want to do. So go ahead and click ‘Setup’. Now we see our ‘Promote Workflow Input Parameters’ window. This will allow us to do a few different things; First of all, we can promote or move our inputs from the reboot host workflow to our workflow, and secondly we can decide to assign default values to them at the same time. As you can see, the ‘Reboot Host’ workflow takes two inputs; one being the host and the other being the force switch. Leave host as it is but if you want you can set a default value of ‘Yes’ to force by selecting the value option and then the yes option. Then click ‘Promote’.
If you look at your Inputs section now you will see that only host is listed. This is because we require the user to tell us or select the host we wish to reboot. But wait, what about force?!?! Well, by assigning a default value to this input parameter we have actually converted this to an attributes. Attributes are available on the General tab. Anyways – this workflow is now complete! Go ahead and select ‘Save and Close’. You will notice that vCO will also handle a bit of version history for us! Awesome stuff!
Alright! We are done with vCO for now. Let’s flip back to our web client and assign this workflow to be executed on certain objects. Navigate through the web client to the vCenter Orchestrator section, then Select vCO Home and look in the Manage tab. This is where we will add our newly created workflow to our right-click context menu when associated with host. Click the + sign to add a new workflow. In the Available workflows browse through the tree until you find your workflow and click ‘Add’, then select the inventory objects to run it on – in our case, just a host and click ‘OK’
So, after all of this we are now ready for the awesomesauce! Get back into your Hosts and Clusters view and right-click on a host. Once the ‘All vCenter Orchestrator Actions’ menu loads have a look at what you see! Reboot Craziness!!! Your workflow!! If you see fit, go ahead and select it to kick off the workflow. You may be prompted for a token delegation – if so go ahead and click ‘Approve’ – I have no idea what this is 🙂 When your workflow window opens you can see that your host has already been pre-populated with our right-click. You can click Finish to start the workflow immediately or Next to setup a schedule of sorts. ***Warning – this will reboot your host *** – don’t know if that’s needed but whatever 🙂
So there you go! We’ve successfully created a test workflow in which we integrated into and executed from the vSphere Web Client. Pretty awesome stuff! I hope you are starting to see some of the benefits of vCO now! Next we will get back on track with our workflow and dig a bit deeper into creating workflows by installing the Powershell plugin and getting vCO to execute a script for us!
My first vCenter Orchestrator Workflow
- Part 1 – Introduction
- Part 2 – Installing vCenter Orchestrator
- Part 3 – Create a test workflow and see the awesomesauce
- Part 4 – A look at the PowerShell plug-in
- Part 5 – A little bit of SQL
- Part 6 – Resources
2 thoughts on “My First vCenter Orchestrator Workflow – Part 3 – Create a test workflow and see the awesomesauce”