CloudStack Collaboration Conference Europe 2013 Recap

This past week I have attended CloudStack Collaboration Conference Europe in Amsterdam. This post includes a short recap of this trip and my experience with the conference.

History and Background

For many years now, I have paid a lot of attention and been pretty deeply involved with virtualization, cloud and other related technologies. There are multiple reasons for that, such as my personal interests and previous work at Cloudkick and Rackspace. A big part of it is also my involvement with an Apache Libcloud project, a Python library which allows you to talk to many different cloud providers through a standard API.

As part of my involvement with Libcloud, I have worked with more than 20 different cloud providers. As such, I have quite a lot of experience with OpenStack and some other providers, but not so much with CloudStack.

Before the conference, my exposure to CloudStack was mainly limited to reviewing CloudStack related pull requests in Libcloud.

I thought this conference would be a great opportunity to change that and accomplish some of the following things:

  • meet some old friends in person
  • make new friends
  • get more familiar with the CloudStack project and the community
  • talk to the existing Libcloud users about their use cases and problems
  • work on the improved CloudStack driver support in Libcloud

At first, I was kinda worried that there won’t be a lot of actual engineers at the conference and the whole thing will, like many other conferences today, turn into a one big sales meeting where everyone tries to sell your their propriety product / appliance / whatever.

Luckily it turned out to be quite the opposite of that. Not many people tried to sell me their proprietary stuff I have no interest in and the audience was full of great engineers which made up for many interesting discussions and a good conference overall.

The Venue

The conference took place in downtown Amsterdam in a historic venue of Beurs van Berlage, close to the central station and red light district. The venue was nice and the WiFi worked great for me so I don’t have much to add here.

Beurs van Berlage.
There was a Christmas market across the street from the venue with tons of food stands with chocolate, waffles, apfelstrudel and many other kind of goodies.

Day 0 - Hackathon, Workshops

First day of the conference was officially a hackathon and workshops day. As noted above, one of my goals for this conference was to meet with an existing Libcloud users and work on improving the CloudStack driver. As such, I have attended a hackathon where a couple of other people and I worked on Libcloud.

Libcloud table at the hackathon.

Overall, the hackathon was successful and we made good progress on the CloudStack driver.

Some of the improvements and changes we made are described bellow.

Easier instantiation of the CloudStack driver

To make working with a CloudStack driver easier, we modified the driver constructor to support passing in the API endpoint address using the url argument.

Before this change, user needed to manually parse the endpoint URL and pass host and path argument to the constructor.

Old code:

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

cls = get_driver(Provider.CLOUDSTACK, host='api.exoscale.com',
                 path='/compute/endpoint')

New code:

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

cls = get_driver(Provider.CLOUDSTACK,
                 url='https://api.exoscale.com/compute/endpoint')

New driver for the Exoscale provider

We’ve added a new driver for the Exoscale provider. Since Exoscale driver is based on the CloudStack one, majority of the work was already done in the past as part of the CloudStack driver. Nevertheless, the change still included some minor refactoring of the CloudStack driver and tests. Those changes mean that adding a new CloudStack based provider driver in the future will be even easier and include just a couple of lines of code.

Philipp and Tobias from CloudControl joined the hackathon to work on adding support for a CloudStack based provider to their PaaS. Since big chunks of their PaaS are written in Python, Libcloud was a good choice for the task on hand.

While they have worked on bootstrapping a couple of CloudStack servers, they have encountered an issue with a maximum size of user-data argument (2 KB). The problem turned out to be a limitation (or an improper use / abuse of HTTP as I would call it) in the CloudStack versions prior to 4.2.0.

In short, all the CloudStack API requests use HTTP GET method and all the values are sent as part of the query parameters. Yeah, I know what you are thinking. It’s anything but RESTful and shows CloudStack’s Java legacy. In any case, I have personally seen even worse APIs while working with some other providers.

This issue was “fixed” in CloudStack 4.2.0 which allows user to send user-data argument in a body of an HTTP request. This “fix” is (imo) just a quick workaround and not fixing all of the API methods will bite them again in the future. There are many other components in the stack such as load-balancers, proxies and web firewalls which don’t particularly like large query parameter values.

Imo, a correct solution would be to move to a “proper” RESTful API where a payload is sent in the body of the (depending on the create / edit context) POST / PUT request.

I don’t want to sound too negative and I appreciate what the CloudStack people are doing, but since an HTTP API is such an important part of a project like CloudStack, I believe that team should prioritize “fixing” their API over things such as EC2 and GCE compatibility layer.

Again, if you work on CloudStack, please don’t take this personally. It’s just my well intentioned feedback about the API.

Anyway, I digress from the original post title and “RESTfulness” is a complex topic which deserves a separate post.

To allow sending of data in the body of an HTTP request, we have refactored and improved the driver in many ways. Existing driver contained some legacy code which only supported sending data as part of the query parameters.

In the end, it turned out that Exoscale, the provider CloudControl people wanted to add support for, still runs 4.0.0 so we couldn’t use this new functionality.

We have discussed a couple of other approaches such as using deploy_node and compressing the user-data argument (CloudInit supposed to transparently handle and uncompress compressed data), but it turns out that 2 KB of compressed data is still not a lot. Because of that, Philipp and Tobias decided to not use user-data functionality and manually install chef on the servers until Exoscale upgrades to 4.2.0.

Discussions about improved support for advanced zones and plans for the future

Currently, the CloudStack driver works great for basic zones, but support for advanced zones is very basic and lacks most of the advanced functionality.

Because of that, we have discussed how we can improve that and evaluated a couple of different approaches we can take.

On top of that, we have talked about other future plans for the CloudStack driver.

First day closed with a dinner and a ~1.25 hour long boat ride through the canals of Amsterdam. Because it was already dark outside and the windows were very small you couldn’t really see much outside. Luckily this didn’t matter since we had a lot of other people to talk to :-)

I'm on a boat.
Dinner.

As always, I was a bit curious so I checked out the ship’s deck. It turns out that some of the bridges are really low so I needed to duck a couple of times to not get decapitated.

Day 1 - Conference day one

On the second day, the sessions started. This also included my session, an introductory level talk about Libcloud + CloudStack. This session was originally planned to be delivered by Sebastien, but a couple of days before a conference, Sebastien asked me if I could do it because one of the speakers couldn’t make it and he was looking at replacing him.

My session went OK, but I made a mistake of not opening a presenter screen with notes and a timer so the session ended up being on the short side. Luckily, this wasn’t a big problem since Sebastien was there and he managed to fill up the time which was left by answering audience’s questions about Libcloud + CloudStack.

Presentation.
Each speaker received a Rasperry Pi with CloudStack pre-installed as a gift. I think that is a great idea for a conference gift, because it encourages all important maker / thinker / hacker culture.

If you are interested in the talk, you can find the slides here. The video recordings of all the talks should be online some time in the next couple of days.

Day 2 - Conference day two

Second day started with a keynote by Mark Burgess of the cfengine fame, followed by different sessions. Similar to the second day, I have only attended a couple of sessions and spent rest of the time coding and talking to other fellow attendees.

Conclusion

Overall, the conference was a lot of fun. I’ve had a lot of great debates about the cloud and other things, met some old friends, made a lot of new ones, learned some new things about CloudStack and got some real-life experience with it.

It also (not so unexpectedly) turns out that CloudStack community is very diverse (apparently there were 30 different nationalities in the audience of ~350 people) and full of many friendly and great people.

A nice sunset I saw at AMS, while waiting to board my plane back home.

If the time and other things permit, I will definitely be attending the conference again next year.