blog

Photo of pancakes by Luke Pennystan on Unsplash

Trying OpenStack with DevStack

by

Many of my recent projects have been single-server web applications using TurboGears or Flask that consume a few other services. While I was thinking about challenges like scaling, it occurred to me that I should take a look at OpenStack. I hope this will give me a better idea of how the cloud (which I take for granted) works.

You can read the history of OpenStack if you’re so inclined.  Here is what matters: it is a set of cooperating services that can be used to build and scale applications.  It is an open source counterpart to some of Amazon’s AWS offerings and it powers the cloud services offered by Rackspace, HP, Red Hat and others.

Getting started

To give OpenStack a test drive on my laptop, I’m using DevStack, a script which makes quick work of deploying a small instance of OpenStack.  It starts with a clean deployment of Ubuntu 12.04 and the DevStack git repository:

git clone https://github.com/openstack-dev/devstack.git

At this point, you can add your chosen configuration values. (I did nothing on my first attempt.) Then, start the stack:

cd devstack; ./stack.sh

So, did it work?  It seems the answer is yes.  Here’s what I see now:

Horizon is now available at http://192.168.5.130/
Keystone is serving at http://192.168.5.130:5000/v2.0/
Examples on using novaclient command line is in exercise.sh
The default users are: admin and demo
The password: secrete
This is your host ip: 192.168.5.130
stack.sh completed in 1603 seconds.

And at http://192.168.5.130:

Software screen capture

A quick check of the dashboard shows that I can launch new instances (which are guests running in qemu, hosted by my Ubuntu 12.04 host running in  VMware Fusion running atop OS X–something tells me virtual doesn’t mean what it used to mean.)  Sweet!  It also shows me that Swift, the object storage service is not running.  I’m playing around with OpenStack mostly because I want to learn more about the object storage service.  (Yes, I could just use Amazon S3, but then I wouldn’t be writing this post.)  It turns out that this is not as simple as you might think.  (If you are not new to OpenStack, bear with me–I’ve been using it for a few hours now.)

The Swift Service

Swift is the name of the object storage service for OpenStack.  It has an optional S3-compatible API and I think it will do what I want–give me an object store sandbox.  After lots of searching and poking around, I came up with this configuration, put in local.conf before running stack.sh:

[[local|localrc]]
ADMIN_PASSWORD=secrete
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
DEST=/opt/stack
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=1
LOG_COLOR=False
SCREEN_LOGDIR=$DEST/logs/screen
RECLONE=yes
enable_service s-proxy s-object s-container s-account
SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5
SWIFT_REPLICAS=1
SWIFT_DATA_DIR=$DEST/data/swift
[[post-config|$NOVA_CONF]]
[DEFAULT]
API_RATE_LIMIT=False

I noticed that deploying DevStack with this configuration took much longer to run.  This surprised me.  The outcome was similar:

Horizon is now available at http://192.168.5.130/
Keystone is serving at http://192.168.5.130:5000/v2.0/
Examples on using novaclient command line is in exercise.sh
The default users are: admin and demo
The password: secrete
This is your host ip: 192.168.5.130

Great!  The Swift tenant accounts are in place and I can see lots of Swift processes running:

$ ps -ef | grep swift | grep -v grep
 troy      1299 54434  4 17:56 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-object-auditor /etc/swift/object-server/1.conf
 troy      1352 54434  0 17:56 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-object-auditor /etc/swift/object-server/1.conf
 troy     54429     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-container-updater /etc/swift/container-server/1.conf
 troy     54430     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-account-auditor /etc/swift/account-server/1.conf
 troy     54431     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-object-replicator /etc/swift/object-server/1.conf
 troy     54433     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-container-replicator /etc/swift/container-server/1.conf
 troy     54434     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-object-auditor /etc/swift/object-server/1.conf
 troy     54435     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-container-auditor /etc/swift/container-server/1.conf
 troy     54438     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-account-reaper /etc/swift/account-server/1.conf
 troy     54439     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-container-sync /etc/swift/container-server/1.conf
 troy     54440     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-account-replicator /etc/swift/account-server/1.conf
 troy     54441     1  0 17:44 ?        00:00:00 /usr/bin/python /usr/local/bin/swift-object-updater /etc/swift/object-server/1.conf
 troy     54604 54603  0 17:44 ?        00:00:00 python /opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v
 troy     54676 54604  0 17:44 ?        00:00:00 python /opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v
 troy     54684 54683  0 17:44 ?        00:00:00 python /opt/stack/swift/bin/swift-object-server /etc/swift/object-server/1.conf -v
 troy     54979 54684  0 17:44 ?        00:00:00 python /opt/stack/swift/bin/swift-object-server /etc/swift/object-server/1.conf -v
 troy     55138 55137  0 17:45 ?        00:00:00 python /opt/stack/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v
 troy     55210 55138  0 17:45 ?        00:00:00 python /opt/stack/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v
 troy     55217 55216  0 17:45 ?        00:00:00 python /opt/stack/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v
 troy     55293 55217  0 17:45 ?        00:00:00 python /opt/stack/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v

I can even use it from the command line:

troy@ubuntu:~$ echo Hello foo > foo.txt
troy@ubuntu:~$ echo Hello bar > bar.txt
troy@ubuntu:~$ swift upload mycontainer foo.txt
foo.txt
troy@ubuntu:~$ swift upload mycontainer bar.txt
bar.txt
troy@ubuntu:~$ md5sum *.txt
f775802ffdb416d737993925223b040b  bar.txt
a2a894025ee13943ee4887bebf6af3f1  foo.txt
troy@ubuntu:~$ swift list
mycontainer
troy@ubuntu:~$ swift list mycontainer
bar.txt
foo.txt
troy@ubuntu:~$ rm *.txt
troy@ubuntu:~$ swift download mycontainer
foo.txt [auth 0.184s, headers 0.212s, total 0.212s, 0.000 MB/s]
bar.txt [auth 0.197s, headers 0.220s, total 0.220s, 0.000 MB/s]
troy@ubuntu:~$ md5sum *.txt
f775802ffdb416d737993925223b040b  bar.txt
a2a894025ee13943ee4887bebf6af3f1  foo.txt

I haven’t added the S3 compatability layer, but I have enough to help me move forward.  If I’ve missed something or you know of a better way to deploy OpenStack for testing, let us know in the comments!

Caveat

Above, I pretended that reconfiguring OpenStack is a trivial thing.  It might be, if you know what you’re doing.  I tried a few different options to get DevStack to pick up my new configurations, but I found that nothing helped me get a configuration deployed cleanly like wiping the DevStack VM and starting again.  Keep in mind that DevStack is a set of shell scripts.  It’s not Puppet or Chef for clouds.  It’s also aimed at developers who just want to get going as quickly as possible.  And for that purpose, it’s probably good enough.

+ more