[This article was written by Yoram Weinreb.]
vCloud, OpenStack & Cloudify
VMWare has been in the front of the virtualization space for many years and is by far the most popular enterprise virtualization solution.
In the recent years, as cloud technology became popular, VMWare released its vCloud product line to target private clouds.
More recently, VMware entered the public cloud space too with its vCloudAir product.
We’ve demonstrated in many posts how Cloudify, has broad support for orchestrating applications on many different clouds with the most popular being OpenStack based clouds and EC2.
Hybrid cloud orchestration - VMWare to OpenStack and back with Cloudify. Go
Obviously adding support for the vCloudAir cloud was an important target for us.
It can even orchestrate applications that span across VMWare and Openstack in the same deployment.
Examining the vCloudAir API it became apparent that the vCloudAir API was heavily influenced from the traditional VMWare products and customer base.
Compared to OpenStack and EC2, it is much IT operations focused than developer and DevOps focused.
This means the API exposes tremendous amount of customization and control power, but at the same time, completing an operation that takes a couple simple api calls, translated to many more calls in vCloud.
In order to support a new cloud in Cloudify, we have to create or customize a plugin that will expose the different objects and interfaces/operation we can do with this cloud.
In my case, as time was short and I wanted to get going as quickly as possible, I chose to use an existing plugin which exposes Apache LibCloud, which itself lets you interact with different cloud APIs from python.
Cloudify already has a LibCloud plugin that was used for EC2 API.
I just extended it to expose the vCloudAir objects too.
This is a work in progress and I currently have just the server objects (server_plugin) exposed as can be see here:
While testing the work I have done with an actual vCloud account, I found that some of the functionality I used in the LibCloud vCloud driver (version 0.15.1) did not agree with the API used for my account. For example, getting network details did not work for me, but listing the networks did work.
Because of this, I had to fork the LibCloud repo and make a few changes to bypass these issues.
My modified version is at:
I used the node-cellar Cloudify blueprint example.
All of the code stays the same and the only difference was focused on the blueprint YAML
import the libcloud plugin definition: imports: - http://www.getcloudify.org/spec/cloudify/3.1m5/types.yaml - libcloud.yaml Change the VM type definition to vCloud: vm_host: derived_from: cloudify.libcloud.server properties: cloudify_agent: default: user: ubuntu key: /home/ubuntu/id_rsa server: default: ### if defined, will serve as the hostname for the started instance, ### otherwise, the node_id will be used #name: no_name ### HOST_NAME"" # image: Ubuntu Server 12.04 LTS (amd64 20140619) # image_name: Ubuntu Server 12.04 LTS (amd64 20140619) image_name: ubuntu_1204_64bit image: ubuntu_1204_64bit ram: 4096 ### FLAVOR_NAME management_network_name: CFY-Internal ### Network name connection_config: default: cloud_provider_name: vcloud access_id: **************@vmware.com@*************** secret_key: *************** host: ***vcd.vchs.vmware.com port: 443The rest of the YAML stays exactly the same. I just took out the security groups and floating IPs definition I did not have ready yet in my vCloud plugin.
Since Cloudify lets you define your cloud application orchestration in an independent fashion than the actual cloud IaaS the application would run on, it is very easy to run the same application on different clouds with almost no change.
Using common management and orchestration as an abstraction to both VMware and OpenStack provides a common management and deployment infrastructure.
The application is kept aware of whether it is running on OpenStack or VMware. However, since the calls to each of the infrastructure components are now centralized into one driver per environment, it is managed once for all the applications.
Additionally, there is a default implementation for the built-in types, so in most cases the user will need to deal with the details of implementations of each element type only for specific customizations.