Fog.io and vCloud Air

calendar Sep 30, 2015 · 5 min read  ·
Share on: linkedin copy

In the last few weeks I have seen some discussions and requests around using fog.io ("The Ruby cloud services library") in the context of vCloud Air.

The short story is that it works just fine.

The long story is below.

If you are reading this post you may be interested in this combo (fog and vCloud Air) so I am not going to spend cycles explaining what fog is. You probably know it already.

I am no fog expert but my understanding is that the master branch repository includes two vCloud Director providers: vcloud and vcloud_director.

I don't know all the history behind this but the vcloud provider seems to be an old provider implemented in the vCloud API 1.5 timeframe. The vcloud_director provider seems to be an extended versions with more capabilities and compatible with the 5.1 version of the vCloud APIs.

I am unsure why the community created the vcloud_director provider instead of evolving the original vcloud one. There are probably good reasons.

Note: everything I tested below has been tested with the vcloud_director provider. In particular I have tested this small ruby program that deploys 20 VMs.

As far as vCloud Air is concerned, you really need to be up to speed with the model, the nomenclature and the architecture. There is no point in reading the rest of this post if you don't read the vCloud Air Technical Background at this link.

If you haven't read the link above you will find hard to follow what comes next.

I have tested successfully the ruby program above leveraging the fog library with the following environments:

  • Standalone vCloud Director 5.5 based cloud
  • vCloud Air Compute service attached to the vchs platform
  • vCloud Air Compute service attached to the vca platform

#1 is really fog's bread and butter. That is what the vcloud_director provider has been built for. Regardless of whether you are connecting to a vCloud Director on-prem private cloud, or a vCloud Air Network Service Provider public cloud, you should be able to use your username, vCD organization, password and the vCloud Director cloud instance FQDN to login into your tenant and use the features provided by the provider itself.

The script that deploys 20 VMs has a "user inputs" section at the very top that is intended to gather a certain amount of inputs some of which are those described above. For a standard standalone vCloud Director deployment those settings may look like this:

1username = “massimo@it20” <- where “massimo” is the user and “it20” is the vCloud Director Organization of my tenant
2
3password = “password”
4
5host = “mycloud.cloudprovider.com”
6
7apipath = “/api”

Important: vCloud Director supports API backward compatibility. Despite my test vCloud Director instance is based on vCD 5.5 itsupports the 5.1 API versions (the version that the vcloud_director provider uses). This is true for #2 and #3 below as well.

#2 is where it starts to get a bit more interesting, as we enter into the vCloud Air domain. If you read the vCloud Air Technical Background at this link you should understand that vCloud Air uses vCloud Director to deliver the compute service. It's then just a matter of understanding what the vCD end-point and the proper Organization is that you need to explicitly configure in fog. There are many ways to extract those info: you can use PowerCLI as shown here, you can use vca-cli, or you can use the vCloud Air UI as shown in this old post.

For my vCloud Air Compute test where the compute service is "attached" to the vchs platform, the vCD end-point settings look like this:

1username = “john@company.com@M592554335-4865” <- where “john@company.com” is the vCloud Air user and “M592554335-4865” is the vCD Organization at that specific end-point
2
3password = “password”
4
5host = “p6v1-vcd.vchs.vmware.com”
6
7apipath = “/api”

#3 is on the same line of #2 but with some additional nuances. How you depict the vCloud Director end-point is slightly different. You can use vca-cli, you can still use PowerCLI but taking a different path than what suggested above (note the use of the "-vca" parameter to query the vca stack). At the time of this writing the new portal doesn't show the vCloud Director end-point of the VDC you are working with. If / when the portal shows it, you can depict it from there as well. Another (quick and dirty) method to spot the input parameters to be used with fog is to parse the portal URL when connected to the VDC you want to work with.

For example, this is the URL (from the web browser) of the vCD instance I want to point to:

1https://au-south-1-15.vchs.vmware.com/api/compute/compute/ui/index.html?orgName=f607ff03-ddfe-4d6d-b7cc-2cb16c3459c7&serviceInstanceId=d90642e9-ue23-44f4-b29c-112202e608fc&…………………`

The very important thing to notice here is that, because of the way the compute service is advertised and exposed on the Internet, the apipath we have to use here (/api/compute/api) is different from the default apipath used so far for the other environments (/api).

For my vCloud Air Compute test where the compute service is "attached" to the vca platform, the vCD end-point settings look like this (note the different apipath):

1username = “john@company.com@f607ff03-ddfe-4d6d-b7cc-2cb16c3459c7” <- where “john@company.com” is the vCloud Air user and “f607ff03-ddfe-4d6d-b7cc-2cb16c3459c7” is the vCD Organization at that specific end-point
2
3password = “password”
4
5host = “au-south-1-15.vchs.vmware.com”
6
7apipath = “/api/compute/api”

Important: don't get misled by the fact that the FQDN of a compute service attached to the vca platform has "vchs" in it. There are backend operational reasons for that.

In closing, if you go through the steps above, depending on the environment you are trying to consume, you will be able to connect successfully to any of these vCloud Director end-points and use the sample program provided to deploy 20 VMs in a VDC of your choice (yes, you can easily tweak the input parameters to only deploy one VM).

At the time of this writing you should also be aware of this limitation when using the vcloud_director provider in the context of vCloud Air under some network configurations conditions. This could be considered a niche use case but it happens to be, incidentally, how it works in vCloud Air (in the vca stack context).

For the records, there are other two issues I opened while testing fog. You can track them here and here.

Enjoy.

Massimo.