Developing tools with the Abiquo API: noVNC token generator
Most of the examples we have provided of how to interact with the Abiquo API are written in Python, so now it’s time to put some rubies in our blog. We will show you how to use Ruby to interact with Abiquo APIs. First we will consume events by connecting to the Outbound API, but we will not process event data, we will just use it as a trigger. When we detect a deploy/undeploy action, we will retrieve more information about deployed VMs by calling the REST API.
In our latest release, Abiquo has introduced an Outbound Event Stream API. This lets you use events that are recorded in your Abiquo powered cloud platform for various purposes.
While it’s easy to see how these events can be used for monitoring and alerts, they can also be used to increase revenue from your platform.
Here are a couple of ideas to get you going:
Creating sales opportunities
In Abiquo, you can set ‘soft limits’ and ‘hard limits’ for each Enterprise (or “tenant” if you prefer) and each Virtual Datacenter. If you set the soft limit to, say, 80% of the hard limit, then you could use the Outbound Event Stream API to send an email to your inside sales team when your customer reaches the soft limit. If your organisation uses a CRM solution such as Salesforce, you can even have this change automatically updated in your CRM records.
Abiquo allow customers to set ‘hard’ and ‘soft’ limits to monitor customers’ usage
Getting closer to the customer
One of the big challenges in self-service environment is that your customer will be creating virtual machines and implementing new applications without you necessarily knowing about it. For a managed service provider, or even an internal IT provider, this reduces the understanding you have of customer projects.
Using the Outbound Event Stream API, you could alert a Solution Architect or Account Manager, perhaps with a CRM integration, to when a customer implements a new Virtual Datacenter or Virtual Appliance. You could also do this with the Abiquo Reporting Enhancement Pack of course, for an overview of this activity.
When developing Abiquo v2.6, simplicity and functionality was the focus and the workflow acceptance tool has achieved just that.
The new workflow feature will allow you to create your own tools to interact with Abiquo processes at the very same moment they are being executed. In short, during certain Abiquo tasks, Abiquo will send an HTTP request with the task details to a configured endpoint. The task details will contain the links to accept or decline the task. It’s as simple as that.
One of the KEY points of Abiquo is that you can use its API to access ALL resources and actions available from the graphical user interface. This enables us to create an infinite number of external applications that you can integrate with your environment or platform. All the API resources are documented on our wiki.
In this article, we are going to present the Abiquo Events Notifier, a Python tool that monitors events performed in Abiquo and based on a configurable list of rules, sends notifications by email to the cloud administrators, enterprise administrators, etc. This tool can be very useful for the cloud administrator in tracking errors on the platform. Also, you can configure the tool to notify your users when a deploy is finished or if a virtual appliance they own has been undeployed. You can find the full documentation on Abiquo DevOps wiki
Here at Abiquo we just released our 2.0-GA version. And among many improvements and goodies we released our API. From the beginning, we have always wanted to stick to RESTFul principles of design. We all agreed that RESTFul APIs when done well are simple to use and easy to understand. We want to not only implement our own clients, but let other people implement their own abstractions of our application. There are many articles on how to version a RESTFul API. In this one I just want to present the thoughts and ideas that are behind the Abiquo API versioning.
RESTFul APIs work with representations. A representation holds the state of a resource. These representations are composed of data, metadata that describes the data, and optionally, metadata that describes the metadata (normally used to verify message integrity). The metadata of a representation is represented as key-value pairs and sent in headers. This metadata includes the data type, or format. And the format of the representation is known as the media type. That is, when a GET request is performed for a resource, what it obtains is its current state in a specific media type. So we decided to handle versioning with media types. Different Content-type header defines the format of the representation. This is called content negotiation. Media types also accept variables, which are also represented as key-value pairs. For example, a valid mime type could be: application/vnd.company.mime+json;version=1.0. This can be very useful for versioning mime types and this is actually how we implemented the versioning. We all agreed to adopt the versioning of media types as the versioning technique for the Abiquo API. We decided to use custom vendor mime types. Custom mime types follow a convention. First the directory, we chose application because we were modelling our data model. Then the media type itself, which is usually in this form: vnd.company_name.type. In the case of an Abiquo rack for example: vnd.abiquo.rack. Followed by the format, for example the XML representation of a rack:
application/vnd.abiquo.rack+xml <rack> <name>example</name> </rack>
By adding the version as a parameter:
We could have gone with the plain, common application/xml. But we thought that, although perfectly valid, it is not strict. It is not strict because clients are not asking for any arbitrary XML but for a specific representation in a specific format. In contrast an Accept header such as */* or application/xml is admitted. We encourage the use of the appropriate mime type though. But we do not admit those very same mime types for Content-type header. The Abiquo API does not deal with just any XML representation. In addition, as the headers arrive before the body, we can reduce network burden if the Content-type or Accept headers are unknown to the Abiquo API or invalid for the resource. One practical benefit is that an API client might be upgraded in parts. As the implementation of the representations proceeds, the media type can be modified.
With versioning we wanted to handle changes, deletions and additions in our application. All of that without breaking the backward compatibility. Let’s say that we have this XML: application/vnd.abiquo.rack+xml
<rack> <name>example</name> </rack>
If we wanted to add a new property to the rack, for example description, we will end up with this representation:
<rack> <name>example</name> <description>An example of an Abiquo rack</description> </rack>
This is the easiest scenario as old implementations of valid clients will just ignore the new property and keep working with the its old representation. Not even a version parameter is needed here. But what if the change is incompatible. For example, we want to further iterate our rack. We realize that a description is not enough and we want to add up to three descriptions. This could be a valid rack.
<rack> <name>example</name> <descriptions> <description lang="en_US">An example of an Abiquo rack</description> <description lang="es_ES">Un ejemplo de rack Abiquo</description> <description lang="es_CAT">Un example de rack d'Abiquo</description> </descriptions> </rack>
Well, this rack is incompatible with clients expecting the old rack version. This is where content negotiation comes in handy. By versioning the rack, a client might actually ask for any of those three representations.
GET /rack/1 Accept: application/vnd.abiquo.rack+xml;version=2.2 -------------- <rack> /> <name>example</name> <descriptions> <description lang="en_US">An example of an Abiquo rack</description> <description lang="es_ES">Un ejemplo de rack Abiquo</description> <description lang="es_CAT">Un example de rack d'Abiquo</description> </descriptions> </rack>
OTHER OPTIONS Tying the version to the actual media type instead of using parameters was an option too. The rack representation could then be: application/vnd.abiquo.rack+xml
<rack> <name>example</name> <rack>
And when modified it would become: application/vnd.abiquo.rack-v2+xml instead of application/vnd.abiquo.rack+xml;version=1.1 But we discarded this because even though it is not the same version of the representation, we felt like it was the very same mime type. Since parameters are something that adds data to the media type we think this is the right place. Another common version pattern for APIs is to add the version number as a path segment.
But we did not like the idea of tying our API version to the URIs, as this is the resource identifier. In our opinion, the resource identifier should stay the same, even though the representations of the resources change.
Today we have announced next release of our revolutionary Cloud Management Software, Abiquo 1.6, that will begenerally available within 45 days. It includes an industry-standard API for Cloud administration, which speeds Cloud adoption by enabling enterprises to cost-effectively deploy and manage Cloud resources centrally. Further vendor independence support, with Citrix XenServer being added to the list of supported hypervisors, enterprise-class network management and multi-datacenter remote services.
“Abiquo’s latest release further demonstrates that we already deliver the management glue that Global 2000 enterprises and service providers need to connect virtual infrastructure resources for any hypervisor to create private clouds,” said Pete Malcolm, CEO of Abiquo. “We’re the first and only offering that delivers this while others are now only talking about vendor-specific solutions that won’t be available until 2011.” “With Abiquo 1.6’s new APIs and other advanced capabilities, companies of all sizes can now seamlessly connect and cost-effectively manage their internal and external virtual enterprises, datacenters, and processes from a single GUI.”
Abiquo 1.5 was the industries first strategic cloud management solution that managed all aspects of the virtualization infrastructure, from the physical cores to the network and storage resources. It was vendor agnostic, allowing drag-and-drop V2V conversions between five of the most popular hypervisors, and practicle, designed from the ground up to be useful to enterprises. It would allow users capture and store stateful virtual images in shared, private, and public image repositories. These repositories allowed customers to view all virtual images, centrally load gold images from an enterprise’s existing storage systems, and deploy them immediately. As a result, enterprises no longer needed to start from scratch on the Cloud; they could leverage and deploy these existing images.
Now with version 1.6, Abiquo is offering a Cloud Operator API, inspired by Sun Public Cloud (Resource Cloud API), enabling an Operator to run a dynamic, scalable cloud that is configured based on automated capacity rules. With this interfaces, Abiquo has removed one of the biggest obstacles to adoption namely leverage and scalability because enterprises can now cost-effectively deploy and manage the growing Cloud resources centrally.
Extending Vendor Independence
Abiquo 1.6 increases vendor independence by adding Cloud management support and virtual to virtual conversion enablement for Citrix XenServer to Abiquo’s existing support for VMWare ESX and ESXi, Microsoft HyperV, KVM, VirtualBox and Xen hypervisors.
In addition, Abiquo 1.6 now offers extended Logical Volume Manager (LVM) storage support on Linux based Servers to manage iSCSI LUNs, adding to the existing support for OpenSolaris ZFS storage technology. The new LVM storage connector is ideal for small deployments or testing environments.
Increasing Enterprise-Class Capabilities
Abiquo 1.6 provides extended multi-datacenter remote services support, which allows the deployment of multiple datacenters without any special, high-end infrastructure requirements.
In addition, Abiquo 1.6 includes advanced network management capabilities including support for 802.1Q VLAN model with trunking, multiple NICs per Virtual machine, multiple Virtual LANS (VLANs) per virtual datacenter, named networks, fully configurable address spaces, Allocation Policy management based on VLAN availability, physical NIC customization, and support for DHCP Relays. These new capabilities are added to Abiquo’s existing network management capabilities including the ability to identify, purchase and assign public IP addresses at a targeted location as well as the ability to centrally track all networks running in virtual enterprises.
Combined, these new network management and multi-datacenter remote services capabilities increase the robustness and scalability of Abiquo’s vendor-independent cloud management solution. For more information about Abiquo, visit www.abiquo.com.