Adopt an op

Here’s a modest proposal: a program to pair up individual OpenStack developers with OpenStack operators to encourage better information flow from ops to devs.

Heres’s how it might work. Operators with production OpenStack deployments would indicate that they would be willing to occasionally host a developer. The participating OpenStack developer would travel to the operator’s site for, say, a day or two, and shadow the operator. The dev would observe things like the kinds of maintenance tasks the op was doing, the kinds of tools they were using to do so, and so on.

After the visit was complete, the dev would write up and publish a report about what they learned, focusing in particular on observed pain points and any surprises that the dev encountered about what the operator did and how they did it. Finally, the dev would submit any relevant usability or other bugs to the relevant projects.

You could call it “Adopt an Op”. Although “Adopt a Dev” is probably more accurate, I think that the emphasis should be on the devs coming to the ops.

Up and running on Rackspace

Rackspace is now running a developer discount, so I thought I’d give them a try. Once I signed up for the account and got my credentials, here’s how I got up and running with the command-line tools. I got this info from Rackspace’s Getting Started guide.

First, install the OpenStack Compute client with rackspace extensions.

sudo pip install rackspace-novaclient

Next, create your openrc file, which will contain environment variables that the client will use to authenticate you against the Rackspace cloud. You’ll need the following information

  1. A valid region. When you’re logged in to your account, you can see the region names. In the U.S., they are:
    • DFW (Dallas)
    • IAD (Northern Virginia)
    • ORD (Chicago)
  2. Your username (you picked this when you created your account)

  3. Your account number (appears in parentheses next to your username when you are logged in to the control panel at

  4. Your API key (click on your username in the control panel, then choose “Account Settings”, then “API Key: Show”)

Your openrc file should then look like this (here I’m using IAD as my region):

export OS_AUTH_URL=
export OS_AUTH_SYSTEM=rackspace
export OS_USERNAME=<your username>
export OS_TENANT_NAME=<your account number>
export NOVA_RAX_AUTH=1
export OS_PASSWORD=<your API key>
export OS_PROJECT_ID=<your account number>
export OS_NO_CACHE=1

Finally, source your openrc file and start interacting with the cloud. Here’s how I added my public key and booted an Ubuntu 13.04 server:

$ source openrc
$ nova keypair-add lorin --pub-key ~/.ssh/
$ nova boot --flavor 2 --image 1bbc5e56-ca2c-40a5-94b8-aa44822c3947 --key_name lorin raring
(wait a while)
$ nova list
| ID                                   | Name   | Status | Networks                                                                            |
| 7d432f76-491f-4245-b55c-2b15c2878ebb | raring | ACTIVE | public=2001:4802:7800:0001:f3bb:d4fc:ff20:06ab,; private= |

There were a couple of things that caught me by surprise.

First, nova console-log returns an error:

$ nova console-log raring
ERROR: There is no such action: os-getConsoleOutput (HTTP 400) (Request-ID: req-5ad0092b-6ff1-4233-b6aa-fc0920d42671)

Second, I had to ssh as root to the ubuntu instance, not as the ubuntu user. In fact, the Ubuntu 13.04 image I booted doesn’t seem to have cloud-init installed, which surprised me. I’m not sure how the image is pulling my public key from the metadata service.

EDIT: I can’t reach the metadata service from the instance, so I assume that there is no metadata service running, and that they are injecting the key directly into the filesystem.