Devstack At One

October 20, 2012 at 10:20 AM | categories: openstack, devstack

First birthdays are always fun...especially the bit where the birthday kidlet is encouraged to make a mess of the cake to the mild amusement of the adults present. At least that's how it worked in the little burg where I grew up. (Little burg? Isn't that redundant?) My parents have pictures of me doing that, I have pictures of my kids doing that, I anticipate the cycle will continue someday.

Now that the OpenStack Grizzly Design Summit is over I realize that DevStack is just over a year old, having been shown off for the first time at the Essex Design Summit in Boston. We should have had a party! Maybe I'll just retroactively declare one of the many during the week to be DevStack's birthday party. Anyone care to vote on which one? (cough*Nebula*cough) Look, DevStack still has a little cache on its face, how cute!

anotherjesse and sleepsonthefloor initially started building DevStack to address their own needs for OpenStack development and exploration. They were scratching an itch as the saying goes, and it soon became apparent that this might be generally useful. Over its first year DevStack has become the de facto quick way to build an OpenStack cloud for developers. While it was (and still is) primarily targeted for development use it has been found in other interesting places, most promintely in the OpenStack Continuous Integration gating tests.

The original goals of DevStack remain as its primary guide:

  • provide an environment for development and basic testing of OpenStack with and quick turnaround times and easy access to debug logs and output
  • provide an example of one way to configure OpenStack and provide a simple mechanism to try different configurations
  • support multiple deployment environments (bare metal, VMs, ramdisk, etc)

We have largely stayed true to those goals and IMHO achieved them in large part. As new uses of DevStack have come to light we added

  • provide a basic platform for CI testing and gating of OpenStack commits

What Just Happened?

Honestly it feels like not much has happened on DevStack since I started working on Grenade. In reality, I look at the commits and see some significant developments that are worth noting for those who don't spend their coffee breaks looking at commit logs. In early October we split off a stable/folsom branch of DevStack and configured it to pull stable/folsom branches from the project repos. Everything below happened before stable/folsom was created.

  • Tell stack.sh to shut up! The logging in stack.sh was re-worked to allow writing the familiar xtrace stream to the stack.sh.log files but only display a limited number of status messages in the console window. Set VERBOSE=False in localrc to relieve your eyes from having to look at that stream that is busier than a VMS boot log.
  • Ceilometer and HEAT are now available! You can now incorporate both projects into your DevStack install in the same install-from-source mode that the other projects use.
  • Cinder is the default volume service! Nova volumes will take a powder sometime during Grizzly so we're using that new kid, Cinder, to provide block storage. Stop by and see how jgriffith is doing, maybe he'll put you on a horse.
  • Get smarter about loading images into Glance from IMAGE_URLS! It is the little things in life, like properly set image disk types in Glance, that make the difference between 'Life Is Good' and 'Life Is Pretty Good'. What's next, setting the sticky bit on public images?
  • Exclamation points are on clearance! Just checking to see if you were paying attention. Unfortunately the only ones left are all in Comic Sans.
  • Keystone backend is SQL by default! default_catalog.templates is dead, long live default_catalog.templates! Unless of course you set KEYSTONE_CATALOG_BACKEND=not-sql (really, we test for 'sql' so anything else resurrects the old way).

Near-term Development

I can her you thinking "OK, all that is well and good, but what have you done for me today?" Humph. Lurking in design summit sessions that decide the future of OpenStack's DNS strategy or hallway^H^H^H^H^H^HDeveloper Lounge conversations about how to refactor MySQL configuration in stack.sh or scruitinizing the debut of Dope'n'Stack's latest release or dutifully searching for non-coffee-or-tea-based caffeine isn't enough?

We added some important things from the design summit to the list, presented here in no particular order so don't get any ideas:

  • sdague's arm should be straightened out by the time he returns home and begins doing core reviews on DevStack. [Ed: After further review it seems that he didn't wait.]
  • In other sdague news, he is also planning to implement support for PostgreSQL. And factor out the aforementioned MySQL support from stack.sh in the process.
  • That pesky new kid Grenade wants, nee demands, the completion of the project re-factoring from stack.sh so it can include the results in the upgrade-* scripts.
  • Rework the dependency system to be more portable across multiple distros. Most of the python dependencies are handled by pip out of the tools/pip-requires files in the project source trees but the remaining packaged dependencies need to be specified per-project to ensure they are present when that project is enabled. The existing system is simple but maybe a little too simple especially to support differences between multiple RPM-based distros (hello OpenSUSE!)
  • Finalize Quantal support. Actually that may be done already but someone should check before he shoots his mouth off and says it is done.

Wild Hares

Try these ideas on for size:

Not everything is a good idea and not everything makes it into the master branch which means often good ideas don't make the cut. Whether good or bad, here are some ideas suggested for DevStack that will not be implemented and here is why:

  • Rewrite in Python? One of the primary goals of DevStack is to demonstrate one simple way to set up OpenStack. We feel that is best served using shell scripts that are accessible to more people, especially to implementors who are not developers.
  • Start/run services under upstart/init/whatever? The OpenStack services run in screen to simplify developer access to stop and re-start the services during the development cycle.
  • Install OpenStack from packages? This mode becomes extremely hard to convert a project from using the packaged code to a repo checked out from GitHub. There may be enough demand to warrant wrapping the Ubuntu or Fedora package installs with some default configuration that produces an end-result similar to DevStack but we're going to leave that for someon else to tackle.

Resources

Please excuse us while we wipe the cache off DevStack's face and get back to the freaking cool job of aiding and abetting the creation of more <echo delay="0.3ms" repeat="6"> Software With Which To Rule The World! </echo>. In the mean time here's where to track down the whos-and-whats mentioned above.