The State of OpenStack…and What’s Next?! (Part One)

Wow, what a crazy month it has been! We’re really excited by all the buzz and activity that’s going on in OpenStack–in IRC ( #openstack) and on the mailing lists (, as well as on Twitter (@openstack) and in the media. But hype time is over and it’s time for us to begin delivering on the promises of OpenStack.

OpenStack Compute and Object Storage already have a number of important features in the code base today including:

  • managing virtual machines
  • network configuration for those VMs
  • a fully distributed, replicated storage system
  • storing, retrieving, and replicating objects and files up to 5GB in size

In addition, we have already released interfaces for controlling an OpenStack environment via a web control panel, iPad, iPhone or Android device.

But there is more coming. Chief Architect Rick Clark recently sent out an update to the community outlining the plans for our upcoming October 21 “Austin” release. This initial release of Compute will advance the project a long way, in that it will allow the community to deploy proofs of concept on hundreds of servers on a single cluster and begin developing on the platform.  This is an important milestone on the path to reaching the long term goals of the project, and will be followed by new releases every 3 months.  We will discuss the follow on releases in another blog post, and in depth at the November 9-12th Design Conference in San Antonio.

There are some important changes and updates in the Austin release that are worthy of further detail.  Let me start with what we know will be available on October 21:

1.  The OpenStack API

The Austin release will include the official OpenStack RESTful API, which initially is based on the existing Rackspace Cloud API (published under Creative Commons in 2009).   It will also include additional functionality such as role-based access controls and additional networking actions. This API will be the official OpenStack API and it will evolve with the platform and needs of the community.

What about support for alternative APIs, such as EC2?  The EC2 compatible API, already in the code base today, will remain and be maintained; however, it is important for the project to have an official API that is tied directly to the OpenStack roadmap and feature set. We want to ensure that future OpenStack innovation can be driven by the community and not be restricted to the functionality of outside cloud APIs. The sub-projects are built in a way that will allow multiple APIs to be supported, so if there is an existing API that is really important to you (or one that comes along in the future), it is possible for you to add in support for that as well.

2.  Hypervisor & Image Support

A key tenant of OpenStack is hypervisor neutrality.  OpenStack currently uses libvirt, which provides an abstraction level for hypervisor management for a number of different hypervisors. The Austin release will contain support for XenServer, KVM, and UML. It also supports VirtualBox, which allows people to launch virtual machines on their laptop, making testing and development easier for community members.

For booting up new virtual machines, OpenStack will make use of the Rackspace Cloud’s imaging framework. The framework is based on a tarball of a bootable filesystem.  We will have more detail on future image support direction soon.

3.  Unifying Compute and Object Storage

Its important that the sub-projects of OpenStack can be utilized independently, but we also want to maximize the interfaces to make the entire system hum.  To that end, the authentication system for both Compute and Object Storage will be unified. We are also making Object Storage available as the image store for Compute servers.

4.  Networking Model

We will be supporting two network models in OpenStack: statically assigned, real Internet IP addresses; and private IP addresses within a dedicated subnet, connected via NATing from a private VPN to the public internet. The API will allow users to choose which model they want. Role-based access controls for firewalling will also be added.

These are features that are already in progress and we are comfortable will be complete for the Austin release. But we would like to get more in! We received a lot of input during the Design Summit in July–and continue to see suggestions roll in from the community. With the community’s help, we would like to get these features for the Austin release as well:

1.  Better Server Volumes

The existing Rackspace Cloud supports several great features for server volume management, and we want to get those into OpenStack as soon as possible: resizing servers, snapshotting volumes, and “Rescue Mode”.

2.  Better Server Management

The existing Rackspace Cloud also has more sophisticated server management tools, which we’re actively porting into OpenStack: “Rescue Mode”, and Web-based console access.

3.  Underlying (Core) Refactoring

We want to have as many people running, working on, and contributing to OpenStack as possible. Pragmatically, that means we need to try and make the codebase as friendly as possible. Current efforts are on three broad tracks:

a.  Packaging, deployment recipes, and installers

b.  Making the programming models as standard and understandable as possible

c.  Abstracting the datastore from the object model (enabling folks to use SQL or alternate KVS systems)

d.  Cleaning up code and providing consistent, useful documentation (read about our new tech writer)

We think these last three items are important and urgent, and hope to get active community engagement on their development. Hopefully they will make it into the Austin release, although since this is a time-boxed release, we can’t be certain.  Our priority will be to deliver a stable set of features rather than broad. If they are not ready by mid-October, we expect the community will be able to deliver them by our next release in January 2011 (more on that later).

Thanks Stackers for getting this project off to a great start!  Please reach out if you have any feedback or need any assistance.

On behalf of the OpenStack Team and Community,

Jim Curry
Chief Stacker
@jimcurry, [email protected]


  1.  Hosting Thoughts » Blog Archive » Two approaches to “Cloud” vendor lock-in
  2.  The State of OpenStack…and What’s Next?! (Part One) | OpenStack News J

Leave a Reply

Your email address will not be published. Required fields are marked *