In January I joined the OpenStack Infrastructure team, which manages the continuous integration system for the project, as well as several other applications and sites that the project uses on a day to day basis. My favorite part about all of this is while I’ve spent several years using open source software in my sysadmin day job and running a couple servers hosting various Ubuntu community resources, I’ve never actually done the actual systems administration itself in an open way.
In the OpenStack project, it’s all done out in the open![1]
The CI tools we use are all open source, the puppet and other configurations we have are all hosted in public revision control (see here) and any changes submitted are made by the same process all other changes in OpenStack are made. They go through automated tests in Jenkins to test applicable syntax and other formatting and the code changes submitted are reviewed by peers and approved by members of the infrastructure team. This has made it super easy it is for the team to collaborate on changes and offer suggestions (much better than endless pastebins or sharing a screen(1) session with a fellow sysadmin!), plus with all changes in revision control it’s easy to track down where things went wrong and revert as necessary.
Last week my colleague James E. Blair spent time reorganizing the documentation for the OpenStack Project Infrastructure. James wrote that the goal of the rewrite was to “to re-orient the documentation as an introduction for new contributors and a reference for all contributors.”
The Project page now links to all of our team resources, from IRC channel (#openstack-infra) to bug tracker.
Each Major System that is maintained by the team now has a page that gives links to all of the current hosts the section of the project is associated with, the puppet configuration files required to make changes to it, links to actual project pages for the resource being used and where to report bugs for it. As an example, check out the new Logstash page that Clark Boylan recently rewrote.
The coolest part about all this is that while the OpenStack infrastructure has always been out there in the open, this all really does make it easier to get yourself familiar with the project infrastructure and able to make small edits here and there in your area of expertise, whether it’s fixing some CSS, adding service to puppet, patching Zuul or updating the very documentation this post is about.
Interested?
If you’re not yet involved with OpenStack, check out the How to Contribute wiki for how to get set up to make contributions to the project.
Once you’re set up, visit the Gerrit Workflow wiki to learn how we use git-review to submit changes for review.
Then have a browse through our shiny new OpenStack Project Infrastructure documentation or our low-hanging-fruit bugs to find something you want to work on and submit a patch!
We could also always use help with code reviews, specifically from folks with Python, Java and Puppet experience, check out Anita Kuno’s great post: Reviewing an OpenStack Patch. Most of what we work on is prefixed with openstack-infra/ in Gerrit.
And feel free to drop by #openstack-infra on irc.freenode.net and ask anyone (I’m pleia2 there) if you want some help getting up to speed or have questions.
[1] Well, almost all in the open. There are some passwords and other authentication that we store in Hiera, but the type of data we store in it is well-documented in our main site.pp.