VMware vCloud Director(vCD) Test Automation

VMware vCloud Director is one of the most popular tools when it comes to full lifecycle management for business infrastructures. The things that make it so popular among vCloud suite users are agility, efficiency, choice, and control to enhance the service experience, simplify application release automation and in turn, achieve the fastest time-to-value. Testing a software is crucial in order to check whether it will deliver what it promises. When it comes to using hosted VMware vCloud Director, it is necessary to create a set of tests which will validate proper execution of vCloud instance. In this blog, I will try to explain the best approach to automate these tests for vCloud Director but first let’s see what is vCloud Director-

What is vCloud Director?

VMware vCloud Director enables cloud service providers to convert physical data centers into highly elastic Virtual Data Centers(VDCs). It is used for secure and efficient data delivery along with multi-tenant resource pooling, data center extension, cloud migration, operational visibility, automation, and multi-site management. Some of the benefits that it offers to cloud providers include operational efficiency, differentiation, hybridity, and security, among others.

Now to explain the test automation process for the vCD, I will take an example where I had to automate different scenarios for one of our clients at Opcito. The client wanted to create resources like vApp template, vApp, network, firewall & NAT rules, VPN, etc; then perform verification on this setup; and at the end delete all the created resources. Now, there are multiple ways to achieve this. But to do this in an efficient way, one must consider the following criteria:

• Low resource utilization
• Ease of automation and maintenance
• Ease of consumption in the CI server
• Ease of running on any region where vCloud Director is installed
• Modularity to run a single test case / single test suite / multiple test cases / all test cases depending on the requirement.

Keeping in mind the aforementioned criteria, we used setup and teardown scripts to create and destroy commonly required resources. The setup and teardown scripts run before and after the execution of test suites respectively. We created a set of test suites, each containing separate functionalities. Thus, resources required by test suites are created and deleted within test cases and after the execution of the teardown script, no object remains in the vCloud director irrespective of whether a test case executes successfully or not.

It will be a good idea to group operations which are to be used from setup, teardown, and test suites and hence we created common functions for such operations. The operations include creating vApp, creating a network, creating firewall rules, etc. The common functions are handy when new test cases are to be written.

There are different tools that can be used to achieve test automation such as pyvcloud, vCloud Director APIs, terraform, and vRO. In the scenario that I will be explaining here, I have used pyvcloud and vCloud Director APIs. I will also be elaborating about the advantages and disadvantages along with a sample code.

The reason behind preferring pytest is the flexibility that it adds to test execution and the inherent set of features and functions like creating vApp, creating a network, specifying firewall rules, etc. These functions come in handy while writing new test cases. The common configurable objects such as network name, template name, IP addresses to be used, public IPs on the edge gateway, etc. are also included in the config file. While going through these files, you can also have a quick glance at objects and values used in test scripts.

Now, let’s have a look at how your setup and teardown scripts will look like –

Setup Script

Setup script includes a setup class with a single test case with separate functions to create expected resources. One can then call these functions from the only test case in this class. For consistency purposes, we have included a test case in the setup script so that we get the report of this test case. This is how the code will look like …read more