South By Slash West

SXSWSimply put, SXSW 2014 was awesome. This year I had a workshop titled Cloud Portability with Multi-Cloud Toolkits accepted. With that came a Gold badge and full access to SXSW Interactive. It’s a pass to insight into the tech industry and I tried to make full use of it.

Friday TechBreakfast

It always helps to start SXSW off with a breakfast burrito. I represented Rackspace and spoke at a morning meetup of the TechBreakfast. The TechBreakfast is a “show and tell” format event where up to five different technologists will demo their technologies from a wide range of industries over breakfast.

Sunday Workshop and IEEE Party

Sunday was the day of the workshop. The intent of the workshop is to give developers hands-on experience making their applications portable across different cloud providers using a multi-cloud toolkit. The benefit is avoiding lock-in to a particular provider by easing the transition from one cloud to another.

The entire workshop is online and you can see the presentation and code by running through these slides. There are multi-cloud toolkits in Java (Apache jclouds), Node.js (pkgcloud), Python (Apache libcloud), and Ruby (Fog). When you get to a slide that let’s you choose which toolkit to use, simply click on your toolkit of choice and follow those particular instructions.

I was able to choose 3 co-presenters and was thankful to have Dana Bauer, Ken Perkins, and Kyle Rames with me during the workshop. We were also able to select some hands-on helpers for the workshop and we’d like to thank Anne Gentle, Jim Salinas, and Egle Sigler for their assistance.

Here’s a great shot of Kyle presenting his section of the workshop.

Kyle at SXSW

After all was said and done, I headed out for some SXSW fun with my wife. Eventually we wound up at the IEEE Technology for Humanity party. Having zero expectations going in, we were surprised by just how much fun it was. It was entirely due to Two Bit Circus providing the good times. Here’s a 12 second video of me dive rolling through lasers.

Monday MythBuster and Booth

On Monday I made sure to catch the keynote by MythBuster Adam Savage. I really appreciated one of his main messages about the inclusion of art in science and technology. Many people don’t understand the creative aspects of engineering and computer science and it’s great to have a champion like Adam bringing these ideas to the forefront. I especially liked his use of the acronym STEAM, science, technology, engineering, *art*, and mathematics.

I also spent a good portion of the day working the Rackspace booth at the SXSW tradeshow. The tradeshow floor is huge and many people from all walks of life are traveling by. My preference is to talk to other developers at these kinds of events but how to find those needles in the haystack?

By doing my job. I connected my laptop to a booth screen and just started doing my job. Reviewing pull requests on GitHub, running DevStack, and a little bit of coding. This got the attention of probably a dozen or so developers throughout the day, they would wander on over, and we would have a good conversation. Hopefully I was able to impart a bit of my knowledge and I learned a few things too.

Tuesday Panic, Portlandia, and Women in Tech

First I caught the session Kernel Panic by Adam Buxton on a whim and I was really glad I did. It was the hilarious tour of the contents of one man’s laptop. YouTube comments, health records, David Bowie, family videos, and everything else. Nothing was sacred. It’s difficult to summarize but highly recommended.

Put a bird on itMy wife and I are both fans of Portlandia so when I saw that Fred and Carrie were doing a panel, I had to attend. The Q&A was bookended by clips from the upcoming season. They had a lot of funny and interesting answers to the audience’s questions. Everything from music to gentrification was discussed. Afterwards I just had to get my Portlandia Activity Book signed. It was also great to learn that Carrie was a big fan of Kids in the Hall. :D

In the evening I headed over to the Austin Women in Tech meetup at the Bat Bar on 6th. This was a great event, sponsored by Rackspace and the OpenStack Foundation, celebrating and encouraging women in the tech industry in Austin. I’m fortunate to work with many skilled women at Rackspace and to be able to support these kinds of initiatives.

Wednesday Slashathon

Anne at SlashathonThis was probably the most work and most fun for me during SXSW. Slashathon was a 12 hour long hackathon put on by the legendary Slash. The goal of the hackathon was to produce apps that would help musicians engage their audience. Me and Anne Gentle from Rackspace were representing Rackspace and I gave a demo during the hackathon kickoff. Our prizes were a Rackspace mountain bike for the top rated app hosted on Rackspace and 1 year in the Rackspace Startup Program for the winning app.

Originally I had intended to just be a resource for other developers during the day and to get some regular work done. Anne wouldn’t have it. She convinced me to execute on her idea for a timeline that showed the past, present, and future of a musicians tour dates.

We know APIs and infrastructure but we needed hackers who were better at the frontend user interface. Luckily one of the Slashathon organizers, Jedidiah, connected us with Diago Fujiwara and Kevin Davis from the Harvard Business Review. These guys were frontend specialists looking for something to hack on and liked the idea.

Ultimately we built as a way for fans to follow their favourite artists across time and space during concert tours. We only got as far as searching for artists, mapping their tour dates, and hosting the whole thing on Rackspace before Anne, Daigo, and Kevin had to leave early.  That gave me time to work up a decent script to pitch to the judges during the demos.

At 7:00 pm Slash, Bram Cohen, and Robert Scoble showed up to judge the applications built during the day. I’ve been speaking in public for a while now and am mostly over my nerves but I don’t mind telling you I was nervous when I got up in front of Slash. I’ve been listening to his music my whole life and wanted to make a good impression…or at least not come off like a meathead. I did my best and hopefully represented our team well. Here’s a shot of me explaining Groupieology to the judges and its potential to connect fans and artists.

Everett at Slashathon

At the end of the day we didn’t place but I got to pitch an app to Slash. So I got that goin’ for me, which is nice.

We did, however, get to give away the Rackspace mountain bike to Fletcher Richman from PivotDesk. And the 1 year in the Rackspace Startup Program and $24,000 in free to hosting went to the Slashathon winners with their SlashTV app.


Many thanks to everyone I worked with, talked to, or shared a beer with during SXSW. It was a great time and I can’t wait until next year!

1 Comment

Posted by on March 23, 2014 in Uncategorized


Fixing my OpenStack Gerrit Permission denied (publickey) problem

I was setting up a laptop to contribute some code to OpenStack according to the Gerrit Workflow Account Setup. When I got to the point of doing the git review -s I hit the error

$ git review -s
Problem running 'git remote update gerrit'
Fetching gerrit
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch gerrit
Problems encountered installing commit-msg hook
The following command failed with exit code 1
"scp -P 29418 .git/hooks/commit-msg"
Permission denied (publickey).

Searching around I found Permission denied (publickey) which was helpful in troubleshooting but didn’t suggest an answer.

The solution was to let OpenSSH know where my private key was. I added the following to my ~/.ssh/config file.

    IdentityFile ~/Box/Keys/id_rsa.openstack

Note: That should be a tab before the IdentityFile!

Leave a comment

Posted by on February 12, 2014 in git, openstack


What Developers Need From API Method Docs

TL;DR Developers need zero ambiguity from API documentation.

I am looking for 6 sections when I’m reading API method documentation: the call, prose, parameters, status codes, error codes and examples.

The Call

The HTTP method and path.

e.g. POST


Keep it simple and succinct. The less words you use the better. Writing lengthy descriptions about what the API call does has a way of letting ambiguity sneak in.


I need up to 5 tables. Some tables might not be necessary, depending on the method and how it gets called.

  • 1 detailing the parameters for the query
  • 1 detailing the parameters for the request headers
  • 1 detailing the parameters for the request body
  • 1 detailing the parameters for the response headers
  • 1 detailing the parameters for the response body

The tables are made up of the following columns.

  • parameter
  • position (if it’s body content)
  • required
  • data type
  • valid range
  • default
  • notes


Parameter Position Required Data Type Valid Range Default Notes
name Yes String 1 to 256 chars N/A The name of the book
pages book.pages Yes Integer 1 to 1,000,000 N/A The number of pages in the book
authors book.authors Yes Array of Strings 1 to 256 chars for each author N/A Alphabetical listing of authors of the book

Status Codes

Detail all possible non-error status codes that can be returned by the method. If this particular status code is accompanied by content in the response body, it should be detailed in a table as above.

e.g. 201 The book was created.

Error Codes

Detail all possible error status codes that can be returned by the method. Actionable hints on how to resolve errors are always appreciated. If this particular status code is accompanied by content in the response body, it should be detailed in a table as above.

e.g. 400 The book was not created.


As complete an example as possible of the request and response.


{ "book" : {
  "title": "How to Write API Method Docs",
  "pages": 200,
  "authors": ["sarah", "steve"]

Note: I realize that the “book” level isn’t really necessary here. I’m just using it to illustrate the use of the position column in the table above.


This is what we need to code to your API. Every bit of ambiguity you remove from your documentation will make us love your API more and more.

Leave a comment

Posted by on January 20, 2014 in documentation


The Dual Advantage of Multi-Cloud Toolkits

The goal of using a multi-cloud toolkit is avoiding cloud vendor lock-in. I examined why avoiding vendor lock-in is important in Keep the Cloud Honest. Toolkits such as Apache jclouds (Java), Apache libcloud (Python), Fog (Ruby), and pkgcloud (node.js) enable this by allowing you to write code that will work the same across multiple clouds such as Amazon Web Services (AWS), DigitalOcean, Google Compute Engine, and Rackspace.

Exactly how the toolkits achieve this matters a great deal. Most people think it’s those interfaces within the toolkit that work the same across multiple clouds that are responsible for this. They’re right but there’s more to it than that.

Those interfaces are sometimes called abstraction layers or portable APIs. First let’s look at the portable APIs. I’m most familiar with jclouds so I’ll use examples from our community.

Portable APIs

These are the APIs that allow you to write code that can run with multiple clouds.

For example, you can write code that stores an object in the cloud and that exact same code can run with storage services such as HPCloud Object Storage, AWS S3, and Microsoft Azure. Companies like Maginatics use this to great effect to store billions of objects across many clouds. Smaller projects like ElasticInbox use it to increase redundancy using multiple clouds.

The same goes for computing resources. You can write code that starts a virtual machine in the cloud and that exact same code can run with compute services such as Rackspace Cloud Servers, CloudSigma, and SoftLayer. This allows a Jenkins plugin to start slaves on different clouds or Apache Stratos to run it’s Platform as a Service across multiple clouds.

The portable APIs do this by supporting features that are common across many clouds. Because these features are common, they are naturally a subset of all of the possible features that a cloud may provide. But what happens when your application requires a feature that isn’t common and isn’t part of the portable API?

No problem. All of the multi-cloud toolkits allow you write code to specific APIs for each cloud so you can use those particular features. But then you’re seemingly headed down the path of vendor lock-in. Not so.

Easing The Transition to Another Cloud

Without multi-cloud toolkits, the normal course of action for a developer working with a cloud is to download the toolkit for that cloud only and write their code using it. For example, a developer downloads the AWS Java toolkit and uses it throughout their application with AWS.

To switch to another cloud, not only do the developers have to tear out the AWS Java toolkit and all of the associated code. They have to download the toolkit for another cloud and that toolkit is going to have a different architecture, different idioms, and a different programming paradigm. Developers will have to understand how it works, learn its nuances and idiosyncrasies, and re-architect their application around it. This is a high cost proposition and high barrier to leaving AWS. Lock-in pure and simple.

With multi-cloud toolkits, a developer will download the multi-cloud toolkit and write their code using it, possibly using specific APIs for particular features to a cloud. For example, a developer downloads the Apache jclouds toolkit and uses it throughout their application with Rackspace.

To switch to another cloud, a lot of code will have to be replaced and refactored but they do not have to download another toolkit. All of the cloud providers in jclouds are architected and written in a similar style so there is a lot of consistency between them. Developers already understand how it works, and are comfortable and efficient with it. They can use their intuition when transitioning their code to a new cloud provider. This is a lower cost proposition and a lower barrier to leaving Rackspace. No lock-in. You can choose the cloud provider that works the best for you.


The value of multi-cloud toolkits is not only in their portable APIs but also in how they can ease the transition from one cloud to another by allowing the developer to reuse all of the knowledge and experience they have gained with the multi-cloud toolkit. Don’t get locked into a cloud provider because it’s too expensive to change your code. Choose a multi-cloud toolkit.

Leave a comment

Posted by on January 16, 2014 in cloud, jclouds


jclouds 1.7.0 Released With Support for OpenStack Queuing, Networks, and Rackspace Auto Scale

jcloudsApache jclouds version 1.7.0 has been released into the wild. This is jclouds’ first minor point version release as an Apache top level project. Community development on the project is continuing to accelerate and there are some major additions I’d like to highlight.


I added support for Queuing (project alias: Marconi). OpenStack Queuing is a robust, web-scale message queuing service to support the distributed nature of large web applications. At Rackspace, our implementation of it is known as Cloud Queues.

Kris Sterckx from Alcatel-Lucent added support for Networking (project alias: Neutron). OpenStack Networking is a pluggable and scalable system for managing network resources, such as networks, subnets, and virtual network interfaces.


Zack Shoylev from Rackspace added support for Auto Scale. It will make the Rackspace cloud react automatically to changes in user demand for your application. By creating a few simple rules that you define and control, you let us know when and how to grow (or shrink) your web or application tiers.

We also added support for the new Rackspace cloud in Hong Kong! You can utilize it by setting the zone to “HKG” in jclouds.

Get Started

Rackspace uses jclouds as our Java SDK for OpenStack and the Rackspace cloud. Go to the [Java section]( of where you will find links for everything you need to get started with jclouds. Be sure to check out the [Getting Started Guide]( and the [Examples]( If you don’t have access to an OpenStack cloud handy, I invite you to kick the tires on jclouds by using the [Rackspace Developer Trial](


Let us know what you think! Feel free to reach out to me, Everett Toews, on Twitter @everett_toews or email the Rackspace developer support team at

I’d also like to invite you to connect with the jclouds community. From there you can join our mailing lists or drop by on IRC to say hi. If you’re looking to add new features to jclouds, you might be interested in How to Contribute.

Leave a comment

Posted by on January 9, 2014 in jclouds, openstack, rackspace


DevStack Havana on the Rackspace Cloud

Cloud InceptionHere’s how to deploy DevStack for OpenStack Havana including Neutron (Network) and Swift (Object Storage) on the Rackspace Cloud. You can use DevStack for testing/development of OpenStack or just learning a bit more about OpenStack and how all of the pieces fit together.

If you don’t have a Rackspace Cloud account, I recommend using the Developer Discount to try this out.

  1. Go to the Cloud Control Panel
  2. Click Create Server
    1. Name: devstack-havana
    2. Image: Ubuntu 12.04 LTS
    3. Flavor: Performance 1 > 4GB Performance (you could probably get away with 2 GB)
  3. Click Create Server and note the password and IPv4 address (when it appears)
  4. When your server is Active, switch to a Terminal and run the following commands:
    1. ssh root@my.ip.v4.address
    2. apt-get -y update
    3. apt-get -y install git vim
    4. git clone -b stable/havana devstack/
    5. devstack/tools/
    6. su stack
    7. cd
    8. git clone -b stable/havana devstack/
    9. cd devstack/
    10. vim localrc # copy in the contents of the one below
    11. ./
  5. To access your DevStack screen session:
    1. sudo chmod o+rwx /dev/pts/0
    2. screen -r stack
  6. To work with OpenStack via the API:
    1. curl -s -X POST http://my.ip.v4.address:5000/v2.0/tokens -d '{"auth": {"passwordCredentials": {"username":"demo", "password":"devstack"}, "tenantName":"demo"}}' -H "Content-type: application/json" | python -m json.tool
  7. To work with OpenStack Nova (Compute) via the command line:
    1. source /opt/stack/python-novaclient/tools/nova.bash_completion
    2. source openrc demo demo
    3. nova image-list
  8. To work with OpenStack via the web browser:
    1. Go to http://my.ip.v4.address
    2. User Name: demo
    3. Password: devstack


Happy DevStacking!


Posted by on December 18, 2013 in devstack, openstack, rackspace


Whistle While You HackTX


HackTX is the biggest hackathon in Texas. It’s a 24 hour annual hackathon hosted by the Hacker Lounge and Technology Entrepreneurship Society student organizations at The University of Texas at Austin. It’s made up of 500 hackers with $10,000 in prizes. By far, it’s the biggest hackathon that I’ve personally attended and I was pretty damn excited to represent Rackspace as a sponsor.

Kick Off

To kick things off, some of the sponsors gave a demo of their APIs (plus associated software development kits) and the kinds of things you can do with their services. I had a chance to demonstrate what the Rackspace Cloud could do for these hackers. I showed them how to use the Developer Discount to sign up for a Rackspace account that they could use during the hackathon and beyond without having to pay for anything. They could use that account to spin up a Performance 1 Cloud Server quickly that would be able to host whatever project they were hacking on. Finally I showed them how to use the Rackspace SDKs to make it easy for them to access other cloud APIs in the programming language of their choice. Knowing that Java was part of the curriculum at UT Austin, I focused on how to use the Rackspace Java SDK, powered by Apache jclouds.

Here’s a short video of the demo I did.

The Hackers

It was great to be surrounded by so many developers (mostly students) all geared up and ready to go.

HackTX Hackers

There was no shortage of passion for coding and getting something cool built. When it came time to go heads down and really start hacking away, I happened to be sitting by a group that was constantly whistling. Sitting there in front of their laptops, coding away, and whistling at their screens. I didn’t think too much of it at the time except for occasionally cringing at an off key whistle.


It turns out I was sitting by the eventual winners of HackTX! They were building a web application that was “Guitar Hero for whistling” and aptly named Whistle Hero. Give it a try, it’s riot. I can’t pull off the Kill Bill Whistle Song but I can do a pretty good Twinkle Twinkle Little Star. Second place went to Relevant xkcd, which is always useful, and third went to an app called Alert Meet.

Congrats to all of the hackers who participated. It was a great hackathon and we hope to see you next year!


Get every new post delivered to your Inbox.