About contributing to OpenStack

In my previous post I got my development environment up and running with all the necessary repositories. So now I can dig in to the actual work 🙂

The project in OpenStack, that I am working on is called “OpenStack Client integration for Manila”. To sum it up with a few sentences, the aim of it is to create an OpenStack client that implements the already existing Manila client. Manila is the OpenStack Shared Filesystems service.

Everything in OpenStack, as much as I have seen so far, is very well documented and a simple google search will give more than enough information about any detail about it, so my post is more focused on how to get through all the information and get a clear vision about steps needed to make a contribution. Basically, I want to create a little cheat sheet for myself to come back to, to copy & paste the necessary commands for every step until I know them by heart.

My work on the project will be based a document that was created and discussed within the whole community beforehand.

So to begin with, I want to test out the already existing manila client commands and doing so, get to know the project a bit more. In order to start testing, I will open Terminal and run:

$ VBoxManage startvm "VM_name" --type headless 

This ^ is quite handy if you (like me) want to avoid the VirtualBox Manager’s guest OS and start your vm from the command line.

$ ssh -p 2522 maari@127.0.0.1 

I am connecting to my vm like so ^, because I set up NAT with port forwarding for the vm.

I just (re)started my VM so I’ll need to run the ./stack.sh script again:

$ cd devstack/
$ ./stack.sh
$ . openrc admin

Now I am all set for testing out the manila commands.

Let’s get coding!

Alright, I have been testing and getting more familiar with the code and now I want to start drafting some code, so what about branches, naming branches, pull requests, code reviews in OpenStack?

First of all, in OpenStack we use Gerrit.

To get started, you’re going to have to sign a contributor agreement and set up your SSH keys. This is a one time task though, and you can do it by following the instructions.

You can find all the repositories set up in your DevStack at /opt/stack:

$ ls -l /opt/stack/ 

The list will contain the basic set of repos plus the additions you made in the local.conf file while setting up your stack.

So, once you have located the desired repository (for this project, I am working mostly with python-manilaclient) and want to get coding, you’ll need to create a new branch for yourself. Branches are named mainly either by a bug’s id number or a blueprint’s name. You can create a new branch from master:

$ git checkout -b <branch_name>

OR :

For example, in my project, the initial setup with some commands implemented has been done already, but not merged yet. So to get on that branch I run:

$ git review -d <change_id>  

where the change_id you get from the open pull request url: “https://review.opendev.org/#/c/<change_id>/ “

Now I have the code, I can test it out in my machine and continue the work.

Since that pull request is about to be merged and already tested out, I will create a new branch from here so I have a dependency on the already existing work but I won’t be messing with that. So now I run the same:

$ git checkout -b <branch_name>

And as my mentor suggested, it is useful to start pushing your code to review early on so you can start getting some feedback. So if you know that your patch is not ready to be merged but you want to get early reviews or help from your mentor, you can flag it as ‘work in progress’ on gerrit. I’ll show you how to do that as well, but first, before committing anything, you’ll want to run some tests on your code:

Always run tox:

$ sudo tox  

this ^ will run all unit tests and pep8

If you want to run just pep8 (code style checks):

$ tox -e pep8

To run one specific unit test:

$ sudo python3 -m unittest -q path.to.your.test_file.TestClass.your_test_name

Now, if tests are passing (or you need reviewers help on why they are failing), commit your changes:

$ git commit -a

* about commit messages –> https://wiki.openstack.org/wiki/GitCommitMessages

OR

$ git commit -a --amend (if you are working on a follow-up patch)

Then, simply:

$ git review

If successful, you will see a message with a link to your commit: https://review.opendev.org/#/c/<your_change_id>/

If you think your patch is ready to be merged and you want to leave it for reviews, you’re done here! If you want to mark it as a work in progress you can open that link, choose reply on top/center of the page and and set -1 on workflow:

All teams in OpenStack have core reviewers and in order for your work to get merged you will need two core reviewers to vote +2 on your patch.

That’s it for now! Thanks for visiting 🙂