Getting Started on Contributing to OpenStack

OpenStack

I have started to become interested in contributing to the OpenStack project. Starting to contribute to such a massive project can seem like a daunting task, and it is. It is only by arming yourself with the proper tools and knowledge prior to contributing, that you will have a smoother process. I created this blog post to smooth that process.

Picking a Project

OpenStack is composed of many different projects for different purposes (compute, storage, networking, telemetry, etc.). Before you start contributing, you must have an idea of which project you actually want to contribute to. In my case I have decided on the Telemetry part, more specifically on Ceilometer.

After you have picked a project, it is time to start reading its documentation and developer documentation to understand how it works. The Ceilometer developer documentation offers good explanations and diagrams of its architecture and components.

Here is another nice guide on contributing to Ceilometer.

Ceilometer Architecture

Understanding the Development Workflow

Development of OpenStack follows a strict workflow. It is imperative that you understand and become familiar on how this process works. Before you even begin coding, there are some “paperwork” that you must do first:

  1. Setup a Launchpad account. Launchpad is Canonical's software collaboration platform.
  2. Join the OpenStack Foundation as a Foundation Member.
  3. Sign the Individual Contributor License Agreement

Understanding Gerrit

From Rant about Github pull-request workflow implementation:

To send a contribution to any OpenStack project, you need to pass via Gerrit. This is way simpler than doing a pull-request on Github actually, all you have to do is do your commit(s), and type git review. That's it. Your patch will be pushed to Gerrit and available for review.

Gerrit allows other developers to review your patch, add comments anywhere on it, and score your patch up or down. You can build any rule you want for the score needed for a patch to be merged; OpenStack requires one positive scoring from two core developers before the patch is merged.

Until a patch is validated, it can be reworked and amended locally using Git, and then resent using git review again. That simple. The historic and the different version of the patches are available, with the whole comments. Gerrit doesn't lose any historic information on your workflow.

Following Rules for Proper Commits

In order for your contributions to be accepted into OpenStack, your commits must follow certain rules. For example:

You can read the complete document here. If your commits do not follow these rules, your patches will be rejected.

Providing Appropriate Tests

You must test your changes first before submitting them. Project repositories generally have several categories of tests:

Tests are run through tox. You can see how to run Ceilometer tests here.

Coding Style Guidelines

Besides following the Python PEP8 Guidelines. OpenStack also enforces some additional guidelines which you may read here.

OpenStack Upstream Training

OpenStack has designed a training program to share the knowledge about the different ways you can contribute to OpenStack and getting familiar with open source. They provide a nice Vagrant development environment for this training which you can install in a virtual machine.

Reaching to the Community

Reaching to the OpenStack community in a smart way is important if you want your contributions to OpenStack to be noticed and accepted. Before you start trying to contribute to a specific project, I recommend you first spend some time observing and learning how the community interacts and how the project's development process occurs.

Some ways to begin interacting with the community:

Further Reading

programming open source openstack ceilometer python

Comments

comments powered by Disqus