OpenStack Hits a Triple with OpenStack on OpenStack

On the 16th July the OpenStack Technical Committee voted to make OpenStack Deployment an official OpenStack Program. Our mission is to “Develop and maintain tooling and infrastructure able to deploy OpenStack in production, using OpenStack itself wherever possible.” For the latest code and documentation visit our incubator repository at https://github.com/openstack/tripleo-incubator. OpenStack Deployment (TripleO) was started by HP as part of our active contribution to OpenStack, in order to fill in core gaps in delivering OpenStack to users.

The story for TripleO goes back a little: 9 months ago I started working on a new project - my first day with HP was 14th October 2012 - the start of the OpenStack Grizzly Summit held in San Diego. I knew a little of OpenStack, but less still about the internals, and yet here I was with a fairly clear challenge: solve the problem of deploying OpenStack for production.

There were already solutions of course - dedicated things like Crowbar, generic solutions like Puppet recipes or Juju charms, but these all had various tradeoffs : complexity, or performance, or excessive overlap with Nova itself... depending on which solution you look at. Monty Taylor (my manager) had put it to me that it should be possible to do something narrow, focused and tasteful, by building on OpenStack itself.

Of course, it wasn't so easy :). For starters, we had to name the thing. We were still debating names 6 months later in Portland, but TripleO had pretty much stuck at that point. We called ourselves that because we're deploying OpenStack On OpenStack - OOO, or TripleO. Secondly, OpenStack is a moving target. There are 16 Programs, and nearly as many waiting in the wings to become official as they mature. Most of them have at least one daemon that needs to run on servers, and new ones are added in every release. Since we started TripleO networking support has been split out of Nova, block storage has been split out likewise, bare metal support was added and is now being split out into Ironic... and it looks like other things like scheduling and complex workflow management may follow. Then there are/were significant gaps in OpenStack's native offerings that affect the ability to do deployments: for instance when we started there was no way to deploy physical machines with OpenStack - and and such we have funded full time development on that since (my colleague Devananda van der Veen is the PTL for Ironic. Likewise the service orchestration layer is still maturing, Clint Byrum - another colleague - is focused on helping Heat meet the needs of bare metal workloads.

We've made significant progress since then of course, we've tested and have confidence in the end to end design, and we can deploy a multi-node OpenStack cloud in a few minutes (using golden disk images). TripleO uses the standard OpenStack cloud approach for application deployments: automate everything, avoid doing repetitive work on machines by using golden images, use Heat to scale and coordinate the cluster... but we use it to deploy OpenStack itself. We haven't finished - not by a long shot - but our preliminary timing suggests we can deploy a full rack cloud in about 12 minutes *today*, and we hope to halve that in the medium term.

Being able to deploy OpenStack easily and reliably is extremely important to OpenStack's success. With the exception of large clouds, deployers don't have time to spend weeks or months getting up to speed on how to layout and tune an OpenStack environment. If we can't deploy a production style OpenStack cloud, we can't meaningfully perform CI testing of the entire cloud - and in fact today OpenStack infra doesn't test the migration of clouds between commits, nor the interoperability of different revisions of components - something that happens during deploys on a regular basis. So we can help increase the quality of OpenStack in a real, meaningful way. Lastly, deploying at scale is sufficiently hard that we believe everyone should be knowledge sharing on the problem ... and the current balkanised set of deployment tools doesn't really cut it. We've deliberately designed TripleO to support working with any of Ansible/Chef/Puppet/Salt - so that organisations can work with the sysadmin tools they prefer and still share the core plumbing to get OpenStack onto their hardware.

HP is fully committed to OpenStack:- we believe that the more successful OpenStack is, the larger the cloud market can become, so we're funding TripleO to help OpenStack be successful, we're funding it to improve how we deliver OpenStack to our customers, and we're funding it to help OpenStack become a better product.

Like all OpenStack projects, TripleO is an open project with open governance: we'd love you to join us in solving this complex deployment challenge and help make OpenStack more successful.

-Rob @rbtcollins
(PTL for OpenStack Deployment)