vCloudAir and Cloudify

VMWare has been in the front of the virtualization space for many years and is by far the most popular virtualization solution for enterprises.
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.

Cloudify, cloud orchestration and automation tool has broad support for orchestrating applications on many different clouds with the most popular being Openstack based clouds and EC2.
Obviously adding support for the vCloudAir cloud was an important target for us.
VMWare vSphere & vCloudAir plugins allow for provisioning resources on vCloudAir as well as hybrid cloud support in heterogeneous environment that are running VMWare and Openstack clouds side by side.
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.
I 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 let 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:
Libcloud Plugin

While testing the work I have done with an actual vCloud account, I foudn out 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 was not working 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:
Modified Libcloud

I used the Cloudify node-cellar blueprint example:
NodeCellar Example

All of the code stay 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: 443

The 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 let you define your cloud application orchestration in an independent fashion then 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.

nodecellar

Using a 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 customization

Advertisements
Image | This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s