Tweet This: Tweet
Share on LinkedIn:
By Steve Kaplan, Kovarus, Cloud & Automation Practice Manager
Recently, we were engaged by a customer to assist with a vRealize Automation (vRA) deployment. As part of this endeavor, a requirement was identified to be able to leverage vSphere Tags as part of the provisioning process for virtual machines. Before I go any further, if you don’t use vSphere or the Tags functionality, keep in mind those are just details to illustrate a point that has no boundaries as far as APIs or specific features go. The specifics here just help paint a picture around why this matters! Let’s get into it!
A few important details to help level set the specifics:
- The customer was on vSphere 6.0
- As noted above, we were implementing support for vSphere Tags into the overall provisioning workflow for a virtual machine to store metadata for provisioned VMs that were readily available in vCenter. In this case, there were 3–4 tags that had to be applied, and if tags did not exist, we needed to create them as part of the provisioning process.
A quick overview for those out in the ether who don’t live in the API docs: vSphere tags and tag categories are part of the vSphere Common Infrastructure Services (CIS). CIS is a component of VMware’s vCloud Suite API, commonly referred to as vAPI. If you are programmatically working with tagging constructs, you’re likely familiar with the vAPI unless you’re mostly working through PowerCLI, which abstracts this away by providing a great set of PowerShell cmdlets to make those operations easier to work with.
The use case itself is something we’ve done a number of times for customers, and we keep all of the building blocks in our reference library of vRealize Orchestrator (vRO) resources. As part of that reference library, we have actions in place to make use of the vAPI plugin in vRO to work with vSphere Tags and Tag Categories, as well as example workflows that can be modified as necessary to deliver on customer requirements.
The testing environment we used for our initial development activities was backed by a vSphere 6.5 environment. All initial results were positive and we were able to execute the workflow below as part of the MachineProvisioned lifecycle state of a virtual machine’s lifecycle.
Where things got fun was when we transitioned these initial workflows into the customer environment and began our unit testing activities against their environment. Right out of the gate on first blueprint deployment, we hit errors in the environment during the tagging portion of the deployment! I’ll paste a snippet of the provided exception we received in vRO when issuing that last action:
TypeError: Cannot find function attach_multiple_tags_to_object in object Dy-namicWrapper (Instance) : [com_vmware_cis_tagging_tag__association]-
For all of the folks looking at that cross eyed trying to make heads or tails of what’s going on there, the key piece of that error message is cannot find function. The simple answer here is that the API replied to our request to apply multiple tags to the virtual machine by saying it didn’t have the function to perform that operation. “But it worked in the lab,” you say! Yes, yes it did. With some quick digging into the documentation and, later, a friendly chat with some folks within the relevant business unit at VMware, we were able to confirm that bulk operations for tags were not available until vSphere 6.5. Luckily, 6.0 has APIs for singular operations, so we were able to work around the problem by leveraging workflow looping in vRO to deliver comparable functionality. The workflow below shows what we’re effectively looping through.
So, you’re wondering why there’s still another three paragraphs here… we fixed the problem and the customer is happy… Right? Well, yes, that is correct! Realistically, this environment isn’t provisioning a lot of VMs in parallel, and they’re only applying three tags to each VM. This was a very workable solution to meet the requirements. But, that isn’t why I’m writing this blog post….
Let’s take a worst-case scenario where a machine is getting provisioned and all 3 tags need to be created: We’re looking at 3 API calls to check / verify the categories exist (and 3 more, if they needed to be provisioned, but we’ll assume they exist), 3 more to check /verify the tags exist, and then another 3 to apply them. In all, that’s 9 calls.
The only real difference, you’ll note, is that rather than being able to bulk apply the tags, we’re forced into applying them one by one. Doesn’t seem too bad for 3 tags in an environment where there isn’t a ton of provisioning happening from day to day. But, let’s think about this a little bit more theoretically: what if there were 10s or 100s of VMs getting provisioned hourly? And what if it was 10 tags that had to get added to each VM? The extra API calls will inevitably start to impact performance of the underlying infrastructure with the number of connections being executed by Orchestrator, not to mention all of the other products and end users performing their operations against vCenter. Applying some common sense, it stands to reason that while it may not be much quicker to apply 10 tags as a single bulk operation to a VM, it is certainly overall much more performant to the underlying infrastructure in a holistic sense to execute a single operation instead of 10.
The real moral of the story here is that platform versions and the enhancements produced within them are important, and something everybody across all segments and verticals should take seriously. It’s human nature to pull up release notes and look at what’s new and just gloss over enhancements delivered to APIs when there are far more attractive topics to fawn over (like, say, an HTML5 web interface). The catch, however, is if your organization has tied their short, medium, or long-term goals around automation and all of the benefits that automation delivers to your customers, keeping those platforms up to date becomes a critical path to being able to deliver a robust set of services within your private cloud offering.