vCloud Automation Center (vCAC) offers a self-service portal and underlying framework for cloud management and automated provisioning of infrastructure services.
For an optimal integration of vCloud Automation Center with 3rd party deployment solutions like Microsoft System Center Configuration Manager, Infoblox and Puppet, you can use so-called “vCAC Workflow Stubs”. Workflow stubs are started when a state change occurs in the deployment process of a virtual machine (or other infrastructure resource/service). These stubs can start a vCO workflow to execute some custom steps. Error handling in this vCO workflow is essential as I will discuss in this article.
The available workflow stubs are:
- BuildingMachine
- MachineProvisioned
- MachineRegistered
- UnprovisionMachine
- MachineDisposing
- MachineExpired
During the vCAC “CloneVM” process the BuildingMachine and MachineProvisioned stubs are executed during deployment. The MachineDisposing stub is executed before the virtual machine is removed from the virtual infrastructure.
You can use the vCO plugin for vCloud Automation Center for an optimal integration and execution of vCO workflows. This plugin offers a framework and ready-made workflows to extend vCAC functionality. The plugin allows you to call a custom vCO workflow in one of the available stubs.
About vCO error handling
When an error occurs while executing one of your vCO workflows during the BuildingMachine or MachineProvisioned phase, the error is reported back to vCAC and the request will show a failed request in the vCAC portal. The virtual machine that was requested will subsequently be deleted.
In the case of an vCO error in the MachineDisposing phase the vCO workflow will be cancelled. Despite this error the virtual machine will still be deleted. In practice this means that the virtual machine is removed, but some objects (for example an AD computer account) might remain in one or more other systems.
Let’s illustrate this with an example of a MachineDisposing workflow:
In this example the MachineDisposing workflow consist of the following steps:
- Remove VM from SCCM;
- Release the configured IP in the IPAM system;
- Remove the VM from the CMDB;
If something goes wrong in “step 1: Remove VM from SCCM”, the workflow fails and step 2 and 3 are never executed! This means the IP address is never released and the virtual machine is not removed from the CMDB. However the VM is removed/deleted from the infrastructure!
The solution
The solution is to include some error handling steps in your workflow. When a part of a vCO workflow causes an error, vCO will quit the workflow or follow the red arrow for error handling.
The next image shows a simple example of some error handling steps incorporated into the workflow:
In this example the MachineDisposing workflow contains the following steps:
- Remove VM from SCCM;
- Release the configured IP in the IPAM system;
- Remove the VM from the CMDB;
- Send an e-mail message to confirm successful/unsuccessful steps;
And:
- Error handling 1;
- Error handling 2;
- Error handling 3.
These error handling steps collect the error message generated by vCO, and ensures the next step in the workflow is continued. At the end of the workflow all error messages (if any) are collected and a Send Notification workflow is called to send an e-mail to an administrator including all error messages. It’s up to the administrator to decide if additional actions are required!
Depending on the exact steps in your BuildingMachine and MachineProvisioned phases, you can include error handling in these workflows as well.
Kudos to Arnim van Lieshout for the interesting discussion we had on this subject.