Maari's Blog

Notes to self, OpenStack

About contributing to OpenStack

As of my last 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”. 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 and more can be read about it in here: .

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 on this 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 need to go to devstack/ in my VM and run :

$ . openrc admin

This will, amongst other things, take care of authentication for you, using Keystone. Keystone is the OpenStack Identity Service and more can be read about it in here –> . When deploying DevStack to your machine, Keystone will be downloaded automatically, as it is part of the basic set of repos.

Once it’s done, I can test out the manila commands using examples from here:

About Git

So far I have been testing and getting more familiar with the code while being on master branch and now I want to start drafting some code, so what about branches, naming branches, pull requests, code reviews in OpenStack?

Well, in OpenStack we use git review, a tool, written by the OpenStack community that encapsulates some Gerrit commands.

To set it up 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 instructions from here –>

So to create a new branch from master, run:

$ 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 this command:

$ git review -d <change_id>

where the change_id you get from the open pull request url: “<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>

Branches are named mainly either by a bug’s id number or a blueprint’s 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 batch 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. Let’s see how to do that now:

First, commit your changes:

$ git commit -a

* about commit messages -->


$ git commit -a –amend (if you are working on a follow-up batch & want to keep the commit message)

Then, simply:

$ git review

If successful, you will see a message with a link to your commit:<your_change_id>/

If you think your batch 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:

And of course, there is a place to read more about it :

About testing

Now needless to say, before commiting anything, you’ll need to test your code.

Always run:

$ tox -e pep8 (code style checks)

$ sudo tox -e py36 (this will run all unit tests)

To run one specific unit test:

$ sudo python -m

*First time I ran this command I got an error : 'No module named testtools' and a fix for me was to run:

$ sudo pip install -r test-requirements.txt

and replacing 'python' with 'python3'. So for example :

$ sudo python3 -m manilaclient.tests.osc.unit.v2.test_share.TestShareDelete


Read more about tox –> & more about testing in OpenStack –>

That’s it for now! Thanks for visiting 🙂

1 Comment

  1. AffiliateLabz

    February 16, 2020 at 2:19 am

    Great content! Super high-quality! Keep it up! 🙂

Leave a Reply