A Path Towards Contributing (Via Commits) In OpenStack

This article originally appeared on Matt Fischer’s Blog. Matt codes, brews beer, hikes mountains, and works at Time Warner Cable.

For 2014, I had a goal of doing 12 contributions (commits) to OpenStack. I set this goal because I wanted to learn more about the different components of OpenStack and I wanted to contribute back to the project. In order to do this, I continued a pattern that I started when I first began working on Ubuntu, one which I consider to be a great way to come up to speed on and contribute to OpenStack. Sometime around May I stopped counting contributions and consider my goal to have been met(*). Since I consider that a success, I’d like to share my process with you here and hopefully it can inspire someone else.

Step 1: Learn About the Project

The first step was to learn more about the project, reading is interesting, but diving in and using is better, so I started with DevStack. This should be everyone’s first step. When you encounter something you don’t understand, go find a blog post or OpenStack Summit video about the subject.

Step 2: Contributing with Bug Triage

Once I had a basic understanding of the parts of OpenStack, I started looking at bugs. Joining BugSquad and BugControl was the first thing I did when I did community work on Ubuntu and doing triage for OpenStack is also a good first step. Start with this wikipage, especially if you’re new to Launchpad. By triaging bugs you can get an idea where the issues are and get a second level understanding of the projects. A bug report might cause you to ask yourself, why is neutron talking to nova in this way? It could be something that was not obvious from playing with DevStack. During this process you can mark bug dupes, ask follow-up questions, and perform other triage work. For details on OpenStack bug triage work, read more here. The best part about Bug Triage for new committers? There is an unlimited and never-ending supply of bugs. So which to pick? I like to focus on areas that I have a basic understanding of and interest in. Pick a few projects that make sense to you and look there.

Step 3: Finding a Bug

The real mission during bug triage is digging for a golden nugget, your first bug. This is more difficult than you’d think. You need to find a bug that you can fix, something relatively simple, because your goal in fixing your first bug is to learn the process. During your bug triage work you may have seen some bugs tagged with “low-hanging-fruit”, these are issues that have been identified as ones that would be simple to fix, a good first choice. If you don’t see an obvious bug tagged thusly, I’d recommend starting with the python-*client projects. I find that this code is easier to understand, easier to test, and has more unclaimed issues. You can also even just pull the source for one you like and look for FIXME notes. Another idea is unit tests, all projects love more tests. And finally, the docs can always use help.

Step 4: Working on the Bug

After finding your bug, get to work on fixing it. Before doing so you have some pre-work to do, like creating a launchpad account and signing the developer agreement. I’m not going to list all these steps, but it’s not too difficult. The next steps are fairly obvious, testing, reviewing, fixing, etc. A brief interlude on testing: I do all my testing during this process against DevStack or in DevStack. I have an up-to-date DevStack VM with me at all times and a git repo with my config changes for it. I’d recommend you do the same. Note, when you make your DevStack VM, give it enough RAM and disk, 2GB RAM + 4GB swap and a 20GB disk should be enough. As for code reviews, keep in mind that you will have to likely go multiple rounds on your code reviews. Most of my changes go at least 3-4 rounds, some more than 10, but don’t lose hope, it will eventually land and it will be awesome!

Anyway that’s my process for getting to a first commit with OpenStack. Hopefully if you’re just getting started this method will work for you. Good luck finding your bug and doing your first commit! If you have some other ideas on any of the stuff I covered, please comment below.