A great deal of work is now behind us and copies of Common OpenStack Deployments just started shipping to the folks who pre-ordered. This seemed to be a good time to reflect upon how the book came to be.
In 2014 I had just completed work on my first book, the 8th edition of The Official Ubuntu Book (the 9th edition came out this past July) with Matthew Helmke. Upon getting the finalized biographical blurbs in, my editor Debra noticed something: I work on OpenStack as my day job.
They’d been looking for authors for an OpenStack book so she asked me if I’d be interested. In May, Debra and I finally met and had a lovely lunch at The Slanted Door, overlooking the beautiful San Francisco bay to discuss the potential and decided to move forward.
At this point I’d been working on the OpenStack Infrastructure team for about a year and a half. The team runs all the development infrastructure for the OpenStack project, as well as the whole continuous integration system where tests are run. We’re largely a consumer of OpenStack clouds, pointing our Devstack Gate tooling (and now, Nodepool) at a series of cloud providers. In my role on the team I learned a lot about OpenStack very quickly by debugging test failures with developers and working with teams to get integration testing going. Of particular note, in 2013 I had spent a chunk of time looking into possibilities for bare metal testing. Then I spent several months latched on to the TripleO team to assist with getting their testing infrastructure going, which had me spinning up multiple instances of OpenStack per day in my local testing environment. This work made me very familiar with how bits of OpenStack were stitched together through what was then a series of bash and Python scripts used to deploy it. In September of 2013 I was familiar enough with OpenStack to give a day long workshop for CodeChix in Silicon Valley, which I wrote about here.
With this firm footing in OpenStack I started brainstorming what I’d like to see from a book about it. Where are the gaps in existing books? Where are the gaps in what people understand about OpenStack? So I started asking people at conferences what they thought of or knew about OpenStack. As I gave talks about systems administration and our open source approach to operations in the OpenStack Infrastructure team, I answered questions people had about OpenStack. I noticed two key trends:
- People had a hard time understanding exactly what OpenStack was.
- Even if they understood that it was nominally to “build clouds” they had no idea how or if it would be valuable to their organization.
To address the first, I realized that OpenStack is pretty overwhelming at first glance. It’s made up of dozens of projects (arguably hundreds, depending on how you count). Each of these projects is hyper focused on accomplishing the task at hand in order to serve the demands of their users. They’re eternally seeking to improve stability, preserve backwards comparability and add features. These are all great goals, but it’s easy to lose sight of the big picture and their place in the OpenStack ecosystem. Valuable books had started coming out to tackle specific components of OpenStack and teams are very excited about speaking on their particular piece of it. It turned out, very few teams were focused on presenting the OpenStack project as a whole. This made it difficult for newcomers to get a good sense of the big picture too. I found that OpenStack was routinely confused with other cloud and virtualization technologies, and confused with other projects that start with “Open” in the name, particularly among technologists who aren’t focused on open source.
How could I help fix this? I wanted a book that would give real world examples that people could relate to. The book begins with a few chapters of introduction to OpenStack, some hit-the-ground-running test tooling (DevStack), a manual installation to understand the pieces that go into OpenStack and key concepts like Networking. Each chapter covering deployment scenarios then starts off by setting the stage for what you’re building and gives examples of the kinds of organizations using it. In Chapter 7, “Public Compute Cloud” we talk about a web hosting company using OpenStack to expand their hosting offerings. In Chapter 8, “Block Storage Cloud” we talk about a film company who is using OpenStack to do a significant amount of data processing. For Chapter 10, “Bare Metal Provisioning” we talk about how a company may want to leverage OpenStack to run their fleet of bare metal systems running databases. By providing these profiles, readers can start making connections to the needs in their own organization.
Once the reader is familiar with how OpenStack may be valuable to them, I wanted to demonstrate a real world way to deploy OpenStack. Instead of playing around with something like DevStack or TryStack, or by using a manual install with local virtualization tooling like Vagrant, I wanted them to experience the actual configuration management tooling that is used in the industry. This is where my fantastic contributing author, Matt Fischer, came in. We’ve worked together on Ubuntu and now are crossing paths again in the world of OpenStack. His expertise is in deploying enterprise-grade OpenStack clouds for a major cable company and routinely gives talks around the world on their strategies for deployment of services and how they’ve used Puppet in their organization. Learn more about Matt’s work on the author bio page.
With my expertise in some of the OpenStack internals and broad knowledge of various projects that we interact with on the Infrastructure team paired with his extensive real world experience deploying OpenStack with Puppet we made a great team. At the same time, on the Infrastructure team we had just started work on Infra Cloud, transitioning from being consumers to running our own, Puppet-driven, OpenStack cloud hosted on servers at HPE. Over this past year I’ve worked with Matt and with my Infrastructure team colleagues to build up expertise in using these Puppet modules and subsequently create, test and explain the deployment scenarios now found in the book.
As I barrel in on completing my fourth year working on OpenStack, I’m really proud of the work we’ve put into this book and the result. We hope you are too.