Guest blogger: Alex Heneveld, CTO at CloudSoft
We recently had the pleasure of hosting a visit from Abiquo; pleasurable because it quickly morphed into a hackathon with Xavier Fernandez which yielded a nicely working integration. A long flight gave me the chance to clean it up and make a Brooklyn pull request (#813) with the net result that Abiquo is now (for all you TL;DR vics) a first-class target for the Brooklyn Catalog.
The session started with the usual describe-and-demo. However it is always the surprises which are most interesting so here’s what surprised me:
- Abiquo has their own API. Is this madness given the momentum of the *-stack bandwagons? I don’t want to have to work with yet another API. But it turns out I don’t have to: they’ve got bindings for jclouds and other client libraries which meant, and as we’ll talk about below, it worked with a lot less fuss than I’m used to.
- It’s a very nice GUI. Pretty is always nice, but more importantly it had clearly been through a few rounds of real usability feedback. The little things that usually irk me had all been solved, like searching for resources … acting on several VM’s at the same time … and hanging on a slow connection. (The down-side is that it’s Flex not HTML5/JS/REST, but Abiquo are on the case so look out for a new version when 3.0 is released later this year.)
It’s multi-cloud. Multi-hypervisor is old news, but there still are not many cloud platforms which can front many locations. Add in wide-area, use a datastore efficiently (Redis, in Abiquo’s case), and include locations which are someone else’s cloud with a different API, and the list is very short. Location is a first-class concept, and the current snapshot version supports AWS locations. OpenStack and CloudStack targets around the corner, hopefully.
Switching focus back to Brooklyn and Cloudsoft AMP: As well as the client libraries, Abiquo offers some good image portability features and chef integration, but it’s still a bit of a hop to having an application on-demand, it’s a jump to having a catalog, and it’s another big step beyond that to having the right policies available — for managing it, responding to failures, scaling out under load, and migrating or spanning multiple locations when demand shifts or costs change. So how about Abiquo + Brooklyn ?
There’s only one way to find out. We start with the pom addition:
<dependency>
<groupId>org.jclouds.labs</groupId>
<artifactId>abiquo</artifactId>
<version>${jclouds.version}</version>
</dependency>And add the access details to the brooklyn.properties :
brooklyn.location.named.MyAbiquo1=jclouds:abiquo:http://<removed>/api/
brooklyn.location.named.MyAbiquo1.identity=<removed>
brooklyn.location.named.MyAbiquo1.credential=<removed>
brooklyn.location.named.MyAbiquo1.locationId=London
And run.
bin/brooklyn launch --app brooklyn.demo.SingleWebServerExample
--location named:MyAbiquo1
And fail. A jclouds error about not finding a suitable image or flavour. Well, by now we’re used to these with private clouds. OS information isn’t always reported right, hardware profiles are an odd size. A while back, @andreaturli added a feature to Brooklyn which lists what profiles are available when auto-selection fails, so a look at the Brooklyn console output tells us the ID’s of the image and the hardware we need in our brooklyn.properties.
brooklyn.location.named.MyAbiquo1.imageId=232
brooklyn.location.named.MyAbiquo1.hardwareId=232/107
Try again. Fail again. Brooklyn gives us an error that the credentials aren’t valid. D’oh, of course. The login password is hard-coded in this image and isn’t programmatically exposed.
brooklyn.location.named.MyAbiquo1.loginUser.password=<removed>
Third time lucky? Mmm no. Abiquo has a maximum VM name length (30-ish) shorter than most, and shorter than the Brooklyn default. But the jclouds-abiquo error tells us, and that’s another quick fix. (For Abiquo this fix is in Brooklyn so the setting below isn’t needed, but in case you’re working on a different cloud this is the magic config, from JcloudsLocationConfig.)
brooklyn.location.named.MyAbiquo1.vmNameMaxLength=30
And now? Yes! We have a VM. Oh no. It won’t install the software. Something about out-of-disk-space? D’oh #2. The image has a tiny disk, nearly full. Correct that with a better image available. (Leave for dinner while this installs.)
The next day, try again: Success!
These teething problems aren’t uncommon with a new cloud — so listing the steps may be helpful to anyone trying out Brooklyn somewhere new. In theory one could instead RTFM, where @jdtoy has done us proud, and avoid the “d’oh” moments, but in the real-world useful error messages are a good thing. Both Brooklyn and Abiquo gave good visibility into what was happening, which meant we could debug the glitches pretty quickly.
Considering this was actually a lab cloud not a serious Abiquo install (hence the tiny image), and a brand new cloud provider API (albeit with strong jclouds support), we were chuffed to get it going so quickly. To meet Abiquo on Thursday afternoon, hack for a bit, squash bugs on both sides, and have a catalog working the same time next day, was a good end to a good week.
Of course SingleWebServerExample was just the starter for ten. With that working, we tried another more interesting application from the Brooklyn catalog. Deploys fine. It has an elasticity policy, so pummel it with load: scale-up on Abiquo works fine too, and scale-back when we ease off. All working fine.
As simple as ABC: The Abiquo Brooklyn Catalog.