What does it mean to be OpenStack?

OpenStack has become something of a lightning rod for media attention – attention which, sadly, focuses reliably on the fear, uncertainty and doubt that any disruptive ecosystem will naturally produce. Much like the eddies that form on the edges of fast-moving water, this open-source project throws off a fair amount of confusion, conjecture and rumor.

I’m hoping to get in front of the upcoming round of media frenzy (which is certain to spin out as soon as someone from the Register, CIO Magazine or Network World bothers to skim recent posts to the OpenStack-PPB list), and try to answer a simple question – what does it mean for a project to be “part of” OpenStack?

Ignoring, for just a moment, the eloquent-but-high-level mission statement of the OpenStack project, I will make three simple observations:

1. OpenStack means: a cloud operating system that meets Rackspace’s needs.
2. OpenStack means: a cloud operating system that meets NASA’s needs.
3. OpenStack means: a community effort that meets the needs of its’ members.

While the relative *order* of these observations is likely to provoke outrage from many members of the OpenStack community, I think it’s still reasonably fair to describe it in this fashion – if OpenStack ceases to meet the needs of Rackspace or of NASA, the founding partners, then it will cease to be OpenStack.

What constraints does this put on new projects?

Many.

What has been talked about, at length and by many of the most prominent members of our community, is scale. Rackspace (and indeed many others in our ecosystem) is a service provider, with (at least) tens of thousands of customer accounts. OpenStack has got to scale.

Also discussed, at least in the earliest days, is development philosophy and methods. No, I’m not talking about “development in the open” (although I think it’s generally a good idea), I’m talking about agile, fail-fast, and test-driven development. I’m talking about continuous integration and good unit test coverage. I’m talking about a working-code-trumps-designs-or-promises attitude.

One thing that *hasn’t* been discussed much, is language. Or more precisely, language consistency. Yes, a foolish consistency is the hobgoblin of little minds – and yet, I think it’s no accident that OpenStack is, thus far, 98% Python (plus or minus a smattering of bash).

I sit on the OpenStack Project Policy Board, and I’m getting ready to make myself fairly unpopular. There are a *large* number of projects in the “affiliated with OpenStack” phase, and a few of them are gearing up to apply for official OpenStack status.

Which brings me back to what it *means* to be OpenStack, and particularly NASA’s needs.
(DISCLAIMER: I no longer work for, at, or in any particular association with NASA. I’m speaking merely from my historical position as the architect of the NASA Nebula project, the precursor to OpenStack.)

NASA, like any US Federal agency, is under near-constant IT attack. Far more than any service provider, we have had to focus on the security of our platform. No, I’m not saying that python is more secure than any other language (and NASA has had its share of security issues with EVERY language and platform) – simply that limiting OpenStack to *as few languages as necessary* keeps the strike surface smaller. It keeps system complexity down. And it makes OpenStack monitoring and maintenance a more straightforward process.

Which brings me back to the process of becoming unpopular.

To the best of my knowledge, there are “related” projects in:

• PHP
• JAVA
• Erlang
• Ruby
• C++(?)

Every one of these projects will be considered on the basis of its own merits, by the Project Policy Board and in good time. But for my part, I’ll be looking at security. I’ll be looking at test coverage. I’ll be looking at scale and, yes, I’ll be looking at language.

This applies equally to new project submissions, as well as to legacy projects from both Rackspace and NASA – even a few that I had always thought *were* part of OpenStack.

Oh, and a final thought – to me, OpenStack has always been about being *pythonic*, even in the rare case when we weren’t (yet) writing Python. Which means, as opposed to Perl, there really is “one way to do it”. I love the fact that OpenStack supports every possible hypervisor – but I hate the fact that the test coverage is not equal for each. I love that we have several (many?) different network models available – but I find the current proposal to write, big-design-up-front, a new-from-scratch OpenStack network component misguided at best, and counter-productive at worst. Ditto for the efforts to write a new-from-scratch replacement for the nova-volumes component. Again back to the principles of agile, test-driven development – unless there’s something fundamentally *wrong* with the architecture of the existing components, this strikes me as a bit of NIH syndrome. Iterative improvement, a long set of carefully reviewed changes to an existing codebase, will keep code quality high and interface pain down.

So if I vote against your project tomorrow – it’s not personal. Really. I’ll be voting against some of my own as well – and yes, that really *is* as weird as it sounds.