The hard life of OpenStack application developers

I’m starting to feel the pain of developers attempting to write applications on top of OpenStack clouds: it hurts, and I haven’t come anywhere close to doing anything special.

I started following the getting started tutorial for First App Application For OpenStack (faafo) and I gut stuck on step 1, authentication. There are way too many things that are convoluted, confusing and sometimes carefully hidden (or ridiculously displayed) on Horizon that make it too hard to get started developing apps on OpenStack. I started following the Get Started document for python-libcloud:

You need the following information that you can obtain from your cloud provider:

auth URL
user name
password
project ID or name (projects are also known as tenants)
cloud region

Looks simple but it’s not. The auth URL doesn’t include the path say libcloud documentation but in practice every cloud I tried behaves differently. DreamHost and Runabove require not only v2.0/ but also /tokens after the base URL (https://keystone.dream.io/v2.0/tokens) while CityCloud and HPCloud seem to work according to the documentation. Some will throw weird errors if you add /tokens. Libcloud is also confusing regarding support for Keystone API v3 (which Citycloud uses): the official docs don’t mention v3 (bug), but a blog post from libcloud maintainer provides examples on how to use it.

Finding the right projectID or name is also challenging because some clouds don’t show the project ID immediately in the web control panel (and not every cloud I tested runs OpenStack Horizon). Chances are you’ll have to find the RC file, which is fairly easy if the cloud you’re targeting is using Horizon.

Even after I found all the pieces, I haven’t managed to authenticate using libcloud on CityCloud, Rackspace (using openstack provider) and HP. Only with OVH I managed to authenticate and get a list of images with my stock Ubuntu 15.04. I managed to authenticate on DreamHost only on Ubuntu 14.04 and on a clean, updated virtualenv.

It took a lot of trials and errors to get rid of the Method Not Allowed errors and get libcloud.common.types.InvalidCredsError: ‘Invalid credentials with the provider’, which at least is hinting that I have guessed the auth_url for Citycloud and HP. But I have no idea why credentials are not accepted, since the username and password are those I use on the Horizon panel on HP and on on the custom Citycloud panel. My guess is that I haven’t guessed correctly the project_name or tenant_id or whatever it’s called. This is too confusing.

OVH seems to works, but it requires the full url:

auth_url = ‘https://auth.runabove.io/v2.0/tokens

it won’t work without /v2.0/tokens.  So, after spending one day reading docs, trying to guess permutations I started thinking that probably libcloud is not a feasible approach.

I’ve started looking at OpenStack Infra homegrown interoperability library shade instead: authentication went smoothly immediately with DreamHost and HP on my machine. At least that part was easy and I managed to make some progress in my test with that, finally. Hopefully by the end of the day I’ll have the FAAFO running on

The end result is that it shouldn’t be this hard, even for a very modest developer like me, following a well written, copy-and-paste tutorial should not be as confusing. A lot of work needs to be done to make OpenStack clouds friendly to app developers.

Intel desperate to further Meego

I spent a few hours listening to Intel’s presentation about Meego and the new app store (another) from Intel. AppUp, the name of the store, is just another store. The only new thing that I remember is that AppUp allows to integrate other stores into this store… For example, if you published an app on AppUp, this will also appear on BestBuy’s app store. Not sure what to make of that: as with many other features of the afternoon, I and others in the audience were not impressed.

Intel will review and validate every app submitted in the store and, contrary to Apple’s total opacity, they have published the validation guidelines. The validation process will take ‘at most’ 7 business days and every updated version of the app will have to go through the validation process again. The developers in the room didn’t like that: it’s a huge problem because if your release has a bug, it may take over a week to send a fix to your users.

Admittedly, this validation process is a hard nut to crack but one would expect that a new app store would at least try. I would suggest Intel to give up the subjective control on the ‘objectionable content’ and relegate porn material in a section of the store behind an additional credit card. I would make this section graphically anonymous and before anybody can access it, they have to enter a credit card number, all the time. Developers that publish bad content out of the porn-wall are permanently banned. Fool proof? No, but neither is the existing system with Apple constantly under fire for its decisions to pass or block apps.

My advice: put automatic checks in place for malware and trust your developers until they screw it up. You can also imagine a crowdsourced moderation system after the publication of the app. A model based on trust may not work but at least it would give Inte’s AppUp a differentiating factor compared to the leading stores.

By the way, if you are developing a sync application, port it to Meego and enter the contest for Best App to Stay in Sync at Intel AppUp(SM) developer program.