The OpenStack Blog Everything in & around OpenStack in written words.

Planning to run, or design an OpenStack Cloud?  There’s a new book you should take a look at – the OpenStack Operations Guide.  Get your free download now at http://docs.openstack.org/ops/!

You may have already seen the blog post, We Did It: Zero to Book in Five Days, from Anne Gentle, the OpenStack documentation coordinator who came up with the idea to write the book sprint-style and gathered the team – including myself.

Our overarching guidance (and why you should read this book) when writing was to share our experiences. The authors have all lost sleep and worked through holidays to nurse OpenStack clouds into a production-ready state. To that end, the book covers two main sections: Architecture and Operations.The aim of the Architecture section is to, once you’ve understood enough about OpenStack to realise that you are actually going to build a cloud using it as a basis, step you through many of the common and non-so-common concerns to deliberate while in design. Some of it might be principles you consider standard already, but others look to specifically address the hard questions specific to this platform. Questions like “How do you scale your OpenStack cloud?”, “How many servers should you buy for control infrastructure?”, “Should your storage be external or in the compute node?” are covered in an opinionated manner, with realistic perspective on what works.This book does not include installation instructions. This is already covered in the installations guides at http://docs.openstack.org/install/, so the book segues into Operations assuming that you now have a working cloud – though a pre-install skim is a good idea too.In the Operations section, we really tried to consider running OpenStack from the perspective of a time-poor systems administrator. It starts with a to-the-point tour of your cloud via the commandline as a way of familiarising yourself with what will be your working environment. Following this is a compendium detailing ways in which you’ll be working with the cloud. “User Facing Operations” attempts to give you enough of a perspective on what users are trying to do at the IaaS level that you can can help them, while “Maintenance, Failures and Debugging” works on the dual principle of fixing broken services, or preventing them from breaking in the first place.Two important chapters end the section – “Customise” and “Upstream OpenStack”. Openstack is as much of a community as it is a software project, and the latter gives some insights on how to interact with the community – including how to get help when you’ve tried everything else. The former, probably the most advanced chapter in the book, assists in taking advantage of the framework to extend it without touching the core code. Hopefully you’ll use the two in conjunction and share your work with the community!For excellent bed time reading – perhaps to help understand that others are in the same boat, and reduce those stress levels – there’s an appendix called “Tales from the Cryp^H^H^H^H Cloud”. Here, a few of us share our OpenStack operations stories to help you understand the processes we go through when the stakes are high.

It’s been a privilege working on this book for you – learning as much as contributing – and I hope you find it useful.

History behind the book:

The creation of this book happened in just five days, but the story that goes with it is a little longer. More or less since people started using OpenStack for their production clouds (let’s call that Cactus timeframe – those before that were fairly ‘brave’) there’s been a request for information on the best practices for designing and running our favourite cloud software. As it were, the small number of people working on documentation were struggling just to keep track of the hundreds of configuration options that make this framework so flexible. Then, in May last year, Anne Gentle created a seemingly innocent blueprint “Create and OpenStack Operators Manual”, and started gathering a team – people who’d spent months sacrificing their sleep to tune their OpenStack deployments, and able to share their knowledge.