Check out this tool library for OpenStack operators

OpenStack operators are a handy bunch, known for doing what it takes to keep their clouds running smoothly. Whether that means cobbling together scripts on the fly to optimize routine tasks — or, as a pair of them put it — using duct-tape, bubble gum and bailing wire.

About three years ago, a common refrain kept coming up at the Operators Meetups: where’s the Operator-focused OpenStack Project?

JJ Asghar, senior partner engineer of Openstack at Chef, decided to make OSOps happen. He realized that there were two issues when discussing tools that operators used: different quality for these patch-up-and-go workaday solutions than the rest of OpenStack code base and operators sucking brainpower by writing scripts that other people had already written.

Enter tools-contrib, what Asghar calls a “dumping ground” for these items. It’s a place for operators to find helpful tools that haven’t yet made it into the tools-generic repository but can help run and administer their clouds. And, yes, that means user beware when it comes to trying them out.

Superuser talked to Asghar about what it can — and can’t — do for you and how you can get involved.

What are the benefits to operators and goals of the tools library?

We can now share a constantly improving toolbox in these repositories from which you can pick and choose what you need, and be inspired to build something new or improved. To be clear, the tools-contrib repository is only a first step to getting something in the tools-generic repository. The tools-contrib is designed to git clone from and get the bleeding-edge scripts and tools that our operators community think are useful, but you realize that they are at your own risk.

The ultimate goal is to get vetted tools and scripts in the tools-generic repository , where there is an agreed upon standard level of coding and support for these tools. The tools-generic repository is something that the operator community should be proud of and has all agreed is helpful. There’s also a chance that the tools added here may be upstreamed to the different projects, highlighting a feature that the upstream project needs.

The tools-contrib repository is also a place to help operators can get Active Technical Contributor (ATC) status, when the OSOps Project becomes a foundation Project à la Big Tent. This has been a huge pain point for the operator community; discussed at some level at every operators Meetup. Until now there has been no operator-focused Project that gives you ATC, and, let’s be honest, operators write code, too.

As a community, not having the official acknowledgement from the OpenStack Foundation has caused unforeseen friction. Having the ability to get ATC through OSOps will allow us to tell our respective companies that we give back to the OpenStack Project as a whole, which, in turn, can help the companies claim our work. We spend hours of our lives learning and running these clouds and this seems like a way we can make the ATC accessible to the operator community.

OSOps first tools-contrib commit!neutron/orphaned_ports.py: initial commit https://t.co/FL6GXkAedZ
/cc @OpenStack

— JJ Asghar (@jjasghar) November 20, 2015

The readme says "use at your own risk," what advice would you give people for trying tools out safely?

Yep, we want to make this clear from the very start, that this code is only checked by core contributors for any blatant coding errors. The best advice I can give is to read the code. Figure out what it does and maybe it’s doing something you haven’t thought about. This is a "dumping ground" for tools and scripts that will ideally get to tools-generic.

More eyes on the scripts in [tools-contrib](https://github.com/openstack/osops-tools-contrib will give a higher possibility of getting these tools into tools-generic. We have a bug tracker that can help track issues with the different scripts and help get a conversation brewing about moving the different tools.

Any contributions/help you’d like from the community?

More tooling and scripts in tools-contrib! Anyone can take anything ranging from a bash script that wraps testing Glance to a full-fledged Ansible playbook and commit it. We have a handful of cores who have volunteered to watch over incoming commits, which will help triage and make sure we have a good turn around on contributions.

If you’re stuck on what you could offer this project, a "status" checker, nagios check, or maybe a wrapper script that does something you have to do daily, this is a place for you to share it with the OpenStack community as a whole. We want to make it as easy as possible for people who run OpenStack clouds to commit code back to the community and this seems like the easiest way.

As I answer this, we are still figuring out our standards and what we consider to be good, and would love to have more input. We have an IRC Meeting on odd weeks, and would love more to join and have more voices heard.

Superuser is always interested in how-tos and other contributions from the OpenStack community, please get in touch: [email protected]

Cover Photo // CC BY NC