It was a cool week for OpenStack gatherings. Down in Washington DC an OpenStack Security Book Sprint was happening, while up in New York City, 20 of us were gathered for an OpenStack Infrastructure Bootcamp.

[pe2-image src=”http://lh4.ggpht.com/-BwzMYcZ6oRM/Uc2AY1dXcJI/AAAAAAAAPCA/ctDMY1gep6Y/s144-c-o/20130627_093725_Prince%252520St.jpg” href=”https://picasaweb.google.com/112421715628617571991/20130628#5894508651453313170″ caption=”20130627_093725_Prince St.jpg” type=”image” alt=”20130627_093725_Prince St.jpg” ]

Why do an infrastructure bootcamp? OpenStack, as a project, is really breaking some interesting new ground when it comes to software process flow and continuous integration. Unlike other projects, that test after code has landed in upstream master, we’ve got this incredible pre-merge test system that ensures that upstream master won’t be broken. It’s a system you need when you have over 550 contributors during a six month cycle. This is something beyond Continuous Integration as people normally think about it, though we realized we’re still quite lacking the words to describe it concisely.

This bootcamp was a great chance to go through that, in detail, and expose some of the areas where more contributors are needed to accelerate the project even further. We had all the “coremudgeons” of OpenStack infrastructure (Monty, Jim, Clark, and Jeremy), folks like myself that have landed some patches, or helped with specific efforts, and folks that were new to the whole thing, and just wanted to learn. Some of this I’d seen before, other bits I saw for the first time, and the whole system now makes more sense in my own head.

There were dinner and drinks after day one (the only day I could attend, sadly), and further ideas for improving the whole system flowed over beer, wine, food, and good company. I was struck again, during all of this, just how amazing of a community OpenStack is. We got 20 people together not to discuss or plan out features on OpenStack, but for features and improvements on the systems that facility OpenStack development. The kind of things we’re working towards are as advanced as semi-automatic failure coloration on build logs, to find statistically infrequent race conditions, upstream, instead of ever letting that hit a user in production. Awesome stuff.

Extra special thanks to Monty Taylor for pulling this together. It was no small task, and this wouldn’t have been possible without all his hard work on logistics to make it happen.