We will be going through the process of how to make a contribution to OpenStack starting from a DevStack install. Contributions can be either code or documentation. By the end of the session, participants should have all the necessary accounts and tools set up for contributing, know how to submit a contribution to an OpenStack project, understand the OpenStack contribution process and have a first contribution completed or underway, as well as know what are the next steps. Participants should already be familiar with git, comfortable with Python as well as have a SSH key pair and virtual machine set up with Devstack prepared ahead of the session. You can find instructions on how to do this in the longer description of the session.
Taking people from a DevStack install to a first contribution.
By the end of the session, participants will:
- have all the necessary accounts and tools set up for contributing
- know how to submit a contribution to an OpenStack component
- understand the OpenStack contribution process
- have a first contribution completed or underway, and know what are the next steps
The process for making both code and documentation contributions is the same in OpenStack. For this session, participants will be encouraged to choose a task of either type.
Participants should have:
- A basic knowledge of git (cloning a repository, committing)
- A SSH key pair (instructions on how to create one can be found online, for instance https://unfuddle.com/support/docs/topics/ssh_keypair)
- A Virtual Machine (VM) with DevStack installed (see below for details)
- Be comfortable with Python
Some familiarity with cloud concepts may be helpful.
Contributing to OpenStack currently requires signing a Contributor Licence Agreement (CLA). If your employment contract has a restrictive IP clause, you may want to check first with your company lawyers whether you can sign it. See https://review.openstack.org/static/cla.html for the text of the licence.
Participants are expected to install DevStack in a Virtual Machine (doing it in a VM is important as DevStack cannot be uninstalled) prior to the training to save time and to avoid overloading the Internet connection on the day.
There are many virtualisation software packages that let you create VMs, for example virt-manager (Linux), Vagrant (Linux, Windows, Mac Os X) or Virtual Box (Linux, Windows, Mac OS X). You should install Fedora 20 or Ubuntu 12.04 in the virtual machine.
The installation instructions for DevStack are available at http://devstack.org : within the VM, clone the repository then run
./stack.sh. After answering the initial questions, the script can take up to 1 hour to run depending on your connection speed.
If you have a problem installing DevStack we can try and solve it during the day - doing one run-through of
stack.sh will at least ensure all the packages and software have been downloaded (save/suspend the VM!). In the end though, while DevStack is an incredibly useful tool, it is not mandatory to contribute. If you didn't manage to install it you can pair with someone on the day for DevStack-related tasks and pick another type of task for your contribution.
30 minutes - Introduction
Introduction to OpenStack and to the session goals
Environment check, start devstack
30 minutes - Setting up (one-time only)
- Launchpad (used for bug tracking, single sign-on)
- The Foundation
- Gerrit + CLA (it uses the launchpad account, how gerrit is used)
- Key pair
30 minutes - Getting started
How to choose a bug, bug trackers, low hanging fruits
Reminder of the different OpenStack projects mentioned in the introduction, as well as the documentation and integration tests. Review team vs committer team, +2 process.
Each participant should pick a project and download the code for that project
Ways to find an easy bug:
- general bug tracker browsing
- adding a unit test
- developer docs also live in the project's repository (typos, clarifications, etc)
10 minutes - Break
45 minutes - Find & work on a bug
Participants work on a small task.
There'll be a few tasks ready for people who struggle to find something (missing tests, mostly) but it's unlikely there will be one ready in advance for everyone. Participants will be strongly encouraged to find a task of their own based on their interests and the advice shared prior to the break.
35 minutes - Submitting the patch
Gerrit for review
The git-review tool
- setting up git-review
- submitting the patch
- how it can be used for reviewing
The next steps (for your patch, and the community)