Using Abiquo with libcloud

February 25, 2013 | 2:57 pm

Recently a new libcloud version was released. This is the first time it includes the Abiquo Compute Driver.

Libcloud aims to be an integration library for different cloud providers. It is defined by its easy integration with plenty of drivers and its easy-to-use philosophy.

Libcloud hosts Compute Drivers, Storage Drivers, Load Balancer Drivers and DNS Drivers. We will focus only on Compute Drivers.

The Cloud has become a heterogeneous world and the target drivers range from VPS providers, through public IaaS providers, to private IaaS providers, and there is even an experimental libvirt system library wrapper to manage your local deployments.

This means the libcloud API is generic. So it is important for to you know the limitations and restrictions (and advantages, of course!) you will have as an Abiquo user if you use Abiquo through libcloud, as well as the preparatory steps an Abiquo Cloud Administrator should follow to provide a good user experience. This post enumerates them.

Design Decisions

Conflicts with Abiquo and libcloud

The VirtualDatacenter concept does not exist in libcloud, and neither does the VirtualAppliance. In libcloud everything is a Node. These Nodes are defined by NodeImages and deployed in NodeLocations. That’s all. This is really simple compared to the idea of multiple VirtualDatacenters with different hypervisor technologies that we have in Abiquo. Not all VirtualImages (NodeImages in libcloud) are compatible with all the hypervisor technologies (and hence, VirtualDatacenters) so we have had to take this into account when defining the Abiquo Compute Driver.

More complex: each VirtualDatacenter can store multiple VirtualAppliances and in Abiquo a VirtualMachine cannot be defined outside a VirtualAppliance. This means that handling VirtualAppliances in the Abiquo Driver becomes mandatory, but it has to be done respecting the base libcloud API methods.

And even more: in Abiquo you can configure a VirtualMachine and register it to a Virtual Appliance without deploying it. You cannot do that in libcloud. So Node/VirtualMachine lifecycles are not exactly compatible.

Virtual Datacenters in libcloud

We finally decided (as we did in the jclouds driver) to establish the relationship between VirtualDatacenter and NodeLocation. So when you execute the list_locations() method you are actually retrieving the list of VirtualDatacenters you have access to:

from libcloud.compute.types import Provider 
from libcloud.compute.providers 
import get_driver Driver = get_driver(Provider.ABIQUO) 
conn = Driver('user','password','http://abiquo/endpoint/api') 
conn.list_locations() 
>> [<NodeLocation: id=6, name=Developers, country=Abiquo BCN, driver=Abiquo>,
<NodeLocation: id=9, name=Ignasi, country=Abiquo BCN, driver=Abiquo>, 
<NodeLocation: id=42, name=MyVDC, country=Abiquo BCN, driver=Abiquo>, 
<NodeLocation: id=33, name=Sergi, country=Abiquo BCN, driver=Abiquo>, 
<NodeLocation: id=32, name=Leader, country=Abiquo BCN, driver=Abiquo>]

The context

Because the content of the locations does not change too much, the locations are stored into the session context. When you run the conn.list_locations() you are just printing them.

If you have created a new VirtualDatacenter in Abiquo and want to see it as a location in an existing libcloud session, you should run:

conn.ex_set_context()

to refresh the context.

Virtual Machines in libcloud

Abiquo’s VirtualMachines are mapped into libcloud’s Nodes. We have covered all the data and extra data needed to create Nodes, but if you are familiar with Abiquo maybe you will find the behavior does not match with the expected one because of the name of the functions and Node states. So the standard Node lifecycle in libcloud could be as shown in the following diagram.

In the above diagram, nodes are libcloud NodeStatesblue arrows are user actions, and black arrows are internal business logic to pass from one state to another.

In Abiquo, you can define a VirtualMachine before deploying it, and we wanted to offer a way to use these defined nodes (always defined in another Abiquo client, because the define_node() function is not exposed in this driver… yet). So there is also the function

conn.ex_run_node()

which fits into libcloud’s Node lifecycle as shown in the following diagram.

Virtual Appliances in libcloud

There is no concept of Virtual Appliances in Libcloud, so we created a new object in the Abiquo Driver: the NodeGroup. A NodeGroup is just a logical group of Virtual Machines that can be handled together. For libcloud’s create_node() method, we have added a keyword to specify in which group (Virtual Appliance) we want the node to belong to. So, there is a new method parameter called group_name.

NodeGroup belongs only to a single NodeLocation, in the same way VirtualAppliance belongs only to a single VirtualDatacenter

If you don’t use group_name in method parameters:

conn.create_node(image=images[0]) 

the driver will create a node inside the group libcloud (default group name). If this group name does not already exist, then it will create the group. If the group exists, it will add the node.

If you specify the group_name in the arguments:

conn.create_node(image=images[1], group_name='virtualapp')

the driver will create a node inside the group with the specified name.

If you create another node the same way:

conn.create_node(image=images[2], group_name='virtualapp')

but if, due to image restrictions, the libcloud driver decides it must be deployed in another location, the ‘virtualapp’ group will be created again (if it does not exist) in that location.

This means there is no way you can receive some kind of restriction error when you create or define NodeGroups. The aim is to be as flexible as possible but not limit the standard libcloud API. This is the reason why we accept a group name instead of the NodeGroup object itself.

Extra Group Methods

Create a group:

conn.ex_create_group(name='virtualapp')

It creates a new NodeGroup.

Destroy a group:

conn.ex_destroy_group(group)

Destroys a group. Here you must set the NodeGroup object. Take care! It will destroy all the Nodes inside the group as well!

List the groups you have defined:

conn.ex_list_groups()

For more information, please see full driver documentation

Define privileges

The Abiquo libcloud driver is designed to be used by standard users without many privileges in the platform. These privileges are required for full feature access:

  • Access virtual datacenters view
  • Manage virtual appliances
  • Edit virtual appliance details
  • Deploy and Undeploy airtual appliances
  • Assign network to virtual appliance
  • Assign volumes to virtual machine
  • Perform virtual machine actions
  • Access Appliance Library view

Because an image is worth a thousand words, here is a shot of the ‘Privileges’ screen in our Flex client:

Abiquo API compatibility

The current release is compatible with Abiquo 2.0 and Abiquo 2.2, which are the versions that most of our customers have installed. We don’t think there would be any problems with newer versions, but we have not tested it with Abiquo 2.3 or Abiquo 2.4 yet.

Next Steps

In the current approach, we have tried to be as “libcloud standard” as possible. We are planning to expand the functionality to IP assignment, volume assignment and more Node states (stop, define..), while maintaining libcloud’s standards, in order to improve the user experience and be more helpful to our customers.

More info

Published by: Xavier Fernandez