Monthly Archives: September 2016

OpenStack Superuser Interview

Following news about the book release, Isaac Gonzalez of the OpenStack Superuser blog reached out to me to ask a few questions about the book. In the interview, he asked me about the audience for the book, how the book is laid out, the role of books like this where we now have more formal training and other valuable OpenStack resources that I have “on my shelf” for expanding OpenStack expertise.

You can read the article here: Considering OpenStack? A new book shows you how to get started

OpenStack QA and Infra teams meet in Walldorf, Germany

I spent this past week in Walldorf, Germany at SAP offices with my colleagues on the OpenStack Quality Assurance and Infrastructure teams.

We were able to spend time working on the next major release of Zuul, debugging on our infra-cloud (which uses the same Puppet modules as the book!), launched our statusbot-driven @OpenStackInfra Twitter bot, added more data sources and announced firehose.openstack.org and more.

Read more about the event over on my blog: OpenStack QA/Infrastructure Meetup in Walldorf

The Dedication

Figuring out how to dedicate this book took some doing. Do I dedicate it to a loved one? Or perhaps the OpenStack Infrastructure team that has shown me so much support over the years?

I ended up dedicating it to the OpenStack Community as a whole, with a special nod to the OpenStack Puppet team.

the_dedication

Text:

This book is dedicated to the OpenStack community. Of the community, I’d also like to specifically call out the help and support received from the Puppet OpenStack Team, whose work directly laid the foundation for the deployment scenarios in this book.

I learned while crafting this dedication that it wasn’t just one team in OpenStack that made me feel welcome. As I’ve made my journey through open source over the past decade and a half I’ve learned a lot about communities, values and inclusiveness. The OpenStack community is really something special.

And in addition to laying the groundwork for the book, the Puppet team is also a wonderful group of people. They’re this amazing operator-heavy team who came together to openly support the tooling they’re all using internally. Since all the deployment scenarios in the book are driven by these upstream Puppet modules, it’s no exaggeration to say that the book wouldn’t exist without all of their work.

Thank You

A couple names on the cover of a book tells you very little about how many people have contributed. The book has an Acknowledgments page, but I figured it would be a bit more public about how grateful I am for their participation in making this book happen.

acknowledgments

I always knew I wanted to work with someone on this book. Early on in my work, I found a few people who offered guidance and did some very early reviews of my first chapters, including Ola Peters, Joe Gordon, Eric Windisch and Christian Berendt. Unfortunately these busy, accomplished people weren’t able to join me in the by-line for the book, so I continued my search!

At the OpenStack Summit in Vancouver for Liberty I finally found my contributing author, Matt Fischer. We had known each other through work in the Ubuntu community but first met to seriously discuss his involvement at that summit. The book truly wouldn’t have such functional deployment scenarios without his enterprise-level expertise with OpenStack. He was also able to reach out to his colleagues Clayton O’Neill, Eric Peterson and Adam Vinsh in areas where they were able to lend their expertise, including Puppet, Horizon and Swift.

I had already been going in the direction of using Puppet for all the deployment scenarios, but given Matt’s experience and the exceptional OpenStack Puppet team, I was ready to go full in with the Puppet-driven book. The OpenStack Puppet project team lead Emilien Macchi helped out with some of our examples, and OpenStack Puppet core Colleen Murphy did a considerable amount of work testing and debugging all the scenarios with us.

There were then subject matter experts. Mike Perez helped with the chapter about Cinder block storage. I had Gordon Chung to work with on Ceilometer metering. John Dickinson of Swift put me in touch with Donagh McCabe, Matthew Oliver, Hisashi Osanai, Christian Schwede and Kota Tsuyuzaki, all of whom had an impact on improving the Swift object storage chapter. After Devananda van der Veen prophetically convinced me to include an Ironic bare metal chapter, Julia Kreger stepped up to review and even did a lengthy video call with me to walk me through how everything fit together. Charlie Crawford chipped in by offering some tips about containers and reviewing that chapter from outside the OpenStack world. I was also fortunate to be local to James Downs, whose networking expertise helped with review of the networking chapter with a focus on OpenStack, and took the time to go over a pile of network diagrams over beer one evening.

There were also some folks I brought in from outside the OpenStack space. My sysadmin friends Jonathan DeMasi and Brent Saner offered their systems perspective, which was very valuable since they are the target audience for the book. They helped make sure the book didn’t make too many assumptions about the cloud-specific expertise of the reader and explained all the concepts clearly. Web developer Pasi Lallinaho, who I work with on the Xubuntu project, also played a role, helping make the HTML pages I serve up in the deployment scenarios are much prettier than I came up with myself.

I also had four people who reviewed the whole book, José Antonio Rey, Mohammed Arafa, Doug Hellman and Chris Zahn. José dutifully tested every single scenario in the book and worked with me when he had trouble with the environment. Mohammed kept me on my toes with clarity and consistency edits, along with offering advice from his own experience with OpenStack. Doug brought his incredible knowledge of OpenStack, the OpenStack community and expertise as a writer to the table as he not only reviewed the book, but gave me the confidence that I was writing something that would be valuable. Chris was my technical editor from Prentice Hall who cleaned up grammar (I seem to have a problem with “that” and “which”) and made sure everything flowed as a clear journey for the reader through the book.

My editor Debra Williams Cauley has been exceptional. We spent almost two years working together on this book and she offered advice, guidance and support throughout. Some parts were really tough to get through, but she made sure we made it to the other side.

My journey in OpenStack would have never been successful without the OpenStack Infrastructure Team, a group of brilliant people who I get to work with every day. My role on this team made me feel comfortable with OpenStack and their support through all my projects on the team has never wavered. I routinely feel honored to count myself as a member of the team that keeps the OpenStack project Infrastructure running well from release to release.

Finally, I had a lot of support from friends and family through this. My co-author on the two editions of The Official Ubuntu Book I’ve worked on, Matthew Helmke, was always ready with a kind word of encouragement or a quick call when I ran into road blocks. My husband Mike Joseph was incredibly supportive throughout, even when I got grumpy or thought I couldn’t finish. He even bought a copy, even though I have a whole pile of them!

How the book came to be

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.

ubuntu_bio

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:

  1. People had a hard time understanding exactly what OpenStack was.
  2. 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.