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 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.

$ cd devstack/

$ ./stack.sh

$ . openrc admin This ^ will, amongst other things, take care of authentication for you, using Keystone. Keystone is the OpenStack Identity Service . When deploying DevStack to your machine, Keystone will be downloaded automatically, as it is one of the basic set of repos.

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 🙂

How to set up development environment for OpenStack with DevStack

DevStack can be used to quickly bring up a complete OpenStack environment for development, based on the latest versions of everything from git master. However running it will make substantial changes to the system during installation, so it is advisable to only run DevStack on servers or virtual machines that are dedicated to this purpose.

With that in mind, I will be setting up a virtual machine using VirtualBox with Ubuntu 18.04 (Bionic Beaver).

I have downloaded VirtualBox from https://www.virtualbox.org/ and installed it to my machine. I can use it now to create a virtual machine and give it 4GB of RAM and 40GB of disk (requirements for DevStack).

Now, let’s start the machine and in the promt window select the ubuntu .iso file downloaded from https://ubuntu.com/download/server .

By hitting start, the Ubuntu installation process will begin and it is pretty straightforward.

Once the installation is complete, let’s configure SSH access to the machine. For that, we need to install openssh-server and configure the network settings.

To install the openssh-server, run:

$ sudo apt-get install openssh-server

Make sure the SSH service is running:

$ sudo service ssh status

If necessary, to start the service, run:

$ sudo service ssh start

To set up network settings we need the local IP of the machine. To get it, run:

$ hostname -I

Now let’s configure the network settings, in this example I will be setting up NAT with port forwarding. So, in the VirtualBox Manager, let’s open Settings/Network/Advanced, click on Port Forwarding and add a new rule:

Make sure to set the Name of the rule to SSH, Guest IP to the value you got with running hostname -I just moments ago and Guest Port to 22.

Now, to access the machine from Terminal for example, run:

$ ssh -p 2522 <username>@127.0.0.1

where <username> is the username, you set up during the ubuntu installation.

Next up, we can start setting up DevStack on the machine. For that let’s follow the steps described here :

$ git clone https://opendev.org/openstack/devstack

$ cd devstack/

To create a local.conf file :

$ nano local.conf

Minimum required config for this file would be :

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

But this file can be customised to run DevStack with selected components. In my case I will be adding config info to include manila and manila-ui.

To include manila-ui, for example, I added:

# manila-ui
enable_plugin manila-ui https://opendev.org/openstack/manila-ui

If you are an intern or applicant like me I suggest ask your mentor how to set up the conf file for all the components you need for your project and make your initial setup as smooth as possible.

Once the file is created, run the script :

$ ./stack.sh (this will take quite some time)

NOTE: If you need to make changes in the conf file afterwards, just run ./unstack.sh, make the desired changes, and then run ./stack.sh again.

Now, when the script has finished, we are all set! All the basic set of repos and any additional ones that are defined in local.conf, will be under /opt/stack/

Application process for Outreachy

Hi there! My name is Maari and I was accepted as an intern to the Outreachy December 2019 to March 2020 round. Outreachy provides internships to work in Free and Open Source Software (FOSS) and I will be working on OpenStack Client integration project. 

So how did I get here?

The first step before anything I needed to submit an initial application to Outreachy. It took me some time to get it submitted, since I was thinking quite a lot about the questions before coming up with my answers. Needless to say, I was over the moon to get through to the next round.

In the next round, I needed to choose project(s) to apply to. In order to apply for a project, at least one contribution for it is needed.  A contribution can be, for example, a small bug fix. 

At the beginning of the second round I was sure that I will be making more than one contribution to a project and maybe even submit an application for more than one project. Well, that did not happen… These projects are big and so are the learning curves. Even if you might figure out how to fix a bug, setting up the development environment might take way longer than you expected if you can manage at all (while being like me, not so experienced in the field yet) and so on. I found out quite fast that for those hours in the evenings, I was counting on (having a full-time job during the application process), I had barely any brain power left to take on this kind of a challenge. Also I tend to get a bit overwhelmed at start of a new project that has a lot of new information. I start doubting my abilities, impostor syndrome and all that. With that being said, the contribution period was long enough for me to get past all of that and of course the support from my mentor from OpenStack helped me the most. 

To get in touch with the OpenStack Manila team, I set up an IRC account and joined the chat. The steps on how to get in touch with the team and mentor are nicely documented on the Outreachy page in every project’s details. The OpenStack team was really welcoming, supportive and helpful, especially my mentor. She helped me choose a bug and supported me throughout making my first contribution. Could not have made it here without her!

So thanks to my awesome mentor, Victoria, I managed to make a contribution and submit my final application to OpenStack Client integration project for Manila. This was also my very first contribution to a FOSS community. I am rather shy and not that confident in my skills yet, so having a mentor and a supportive team will help me tremendously to become a member of the community. I am so excited to have this opportunity and to take the most out of this experience.