OpenStack Developer’s Guide

In the previous post, we talked about how to set up an environment for OpenStack development. Today, we will talk about solving OpenStack bugs and uploading a patch set on launchpad.

Before this, first let me tell you what launchpad is. Launchpad is a community for developers, where developers from all around the world post bugs and blueprints for developers of all levels. For example if you are at beginner level, you can start contributing to the community by simply commenting in codes, correcting spelling mistakes in documents, or writing a required document. Such bugs and blueprints are tagged as “Low hanging Fruit”.

Account Setup:

Before starting, please make sure that you are a part of OpenStack development community. For this, you need to have your:
1-Launchpad Account,
2-OpenStack Foundation Account (Foundation Member),
3-github Account,
4-review.openstack account.

Contributer License Agreement:

After setting up all the accounts, you need to agree to the Individual Contributer License Agreement and provide the contact information. This is an important step. Without providing the contact information,  you won’t be able to upload your patch set. For agreement, open the above link and click “New Contributer Agreement” and Check the radio button “ICLA”.

SSH Key Submission:

Next step is to submit an SSH key to gerrit code review. First generate SSH key on your local machine. For this, please run the following commands on your local machine terminal.
git config –global user.name “FirstName LastName”
git config –global user.email “youremail@email.com”

Then run “ssh-keygen” on your terminal. Confirm the default path .ssh/id_rsa. Enter the password or just press “Enter” to leave it blank. Open folder “~/.ssh”. You will see two files, id_rsa and id_rsa.pub. Please note here, id_rsa.pub is your public key and you can share it with others. Now open the link provided above to add SSH key and click add. Open file “id_rsa.pub” copy the whole content and paste it in space provided on web link.

Install git-review:

Git review is a tool, that contains all the details of Gerrit, Code review used in openstack. It is the most important tool for uploading the patch set.

For Ubuntu: “apt-get install git-review”
For Fedora and RedHat: “yum install git-review”
For Mac: “pip install git-review”

All the above mentioned steps are one time only and you don’t have to repeat them the next time you want to solve the bug and upload a patch set.

Working on Bugs:

Start with a simple bug. For example you can start with correcting spelling mistakes or commenting on codes. The OpenStack community provides you every possible opportunity to help and contribute to the OpenStack development. Don’t think too much pr try to do a lot in the beginning, just go through a bug and if it seems doable, assign it to yourself. Don’t start thinking about the solution to solve the bug directly. You will get confused and won’t be able to solve the bug. Just assign the bug and start understanding the code. Assigning yourself is important, so that, everyone can know that you are fixing that bug. Click on the pencil under the “Assigned to” column. This will open a window and show you an option “Assign me”.  The screen shot below shows the pencil from where you can assign yourself.

capture

Click on “Assign me” to assign that bug to yourself. Now that bug is in-progress mode, you are responsible for fixing this. Don’t worry if you can’t fix the bug, remove yourself from assignees.

Start understanding the code and what needs to be done in order to fix the bug. If you don’t want to solve documentation or comment bugs, then start with the bug which already has a patch set. From the patch set you can know which files you have to study, and where you have to make some changes to solve the bug.

After assigning, start fixing the bug. If you haven’t cloned the whole OpenStack repository, then first do this or you have’ll to clone it every time you need to fix a bug. For example, if my bug is that of neutron, I will clone the neutron repository before starting the bug. Clone the repository in your local machine. For cloning find the path of git repository. e.g:
capture

Copy the git repository path. Please note, the path with extension “.git” can only be cloned. Cloning means you can access the source code and you can make some changes to solve the bug. Open the terminal on your machine and type:

“git clone <copied’.git’path>”

Now move to the cloned directory, for example “cd neutron”. For checking the remote repository, type: “git remote -v”. It will show you the remote git repository to which your cloned repository will push the changes to. As you have to publish your changes to launchpad, your local machine should also be connected to review.openstack. In order to make that connection, please type the following command with your user name in your terminal:

“git config –global gitreview.username “

After this, type

“git review -s”

Now your machine is connected to Gerrit Launchpad and ready to publish your changes on gerrit code review. For checking run the command: “git remote -v”. It will show you push and fetch for gerrit and github.

Next, check the git branch by typing “git branch”. Terminal will show “master”. This means now you are in master branch. Before making changes, you have to make a new branch and switch to that new branch. For this, run the following command:

“git checkout -b <yourBranchName>”

Now, if you check your branch by running the command: “git branch”, it will show you your new branch. “git status” command is used to check the status of your bug and the changes you made.

Now open the file and make changes. Edit all the desired files to fix the bug and save the files.

Testing:

Before submitting your changes, test them on your local machine. There are three methods of testing.

1-Tox:

In your cloned repository, there would be file “tox.ini” you have to run this file. This can be done by running a command “tox” in your terminal. It will take a lot of time. The result will show either the changes you made are correct or causing any error in other files.

2-Nosetests:

Simply run the command “nosetests”. This will start a test and show you the results in the end. If this shows “OK”, this means everything is o.k. and there is no error.

3-run_test:

In your cloned repository, there would be a file “run_tests.sh”. This bash file will do all testing for you. You can run this file by running command “./run_tests.sh”. In the end it will show you all the results.

If all the tests show a positive response i.e. no error and everything is fine, continue to committing a change.

Committing a change:

After testing you have to commit a change. Run the following command:

“git commit -a”

This will open a file where you have to write a commit message. There is a fixed format for commit message. The format is as follows:

  • Blank Line
  • Title(What will changes do. Length should be <50)
  • Closes-Bug: <Bug-Number>
  • Explanation

Keep in mind, while making changes to any file or writing commit message, there are some standards for OpenStack development. You have to follow those standards. Otherwise, your bug will not be considered correct.

Submitting a change:

Final step is submitting a change. After committing the changes you have to submit your change. For this, run the following commands:

“git remote -s”

“git review”

If this shows OK, this means change is submitted successfully. Lets suppose you submitted your bug and it shows some errors. Then you have to update a change. Fix the errors and then amend the commit message. Run the command:

“git commit -a –amend”

Save the commit message and run “git review”. You can check your submissions at review.openstack.org.

Re-basing your patch set:

Sometimes, while you are working on one bug, someone solves another bug and master code is updated on github. But you have old version of code because you cloned the repository before that change. But when you upload your patch set, Jenkins tests your patch set with new version of code. So, merge conflicts may occur  on some files. For solving that issue, you have to re-base your patch set.  For this, first switch to master branch:

“git checkout master”

then run the following command:

“git pull –f-only origin master”

then you need to download the latest patch set from gerrit. For this, run the following command:

“git review -d <BugNumber>”

Now, re-base your branch:

“git rebase master”

Some files will be automatically merged. But some files will show “conflict merge error”. You have to remove that conflict and then add these files separately in your branch. e.g. file a.py:

“git add a.py”

then continue re-basing:

“git rebase –continue”

Congratulations! You have submitted your first bug report. Hope it helps you a lot. Please comment if you find any difficulty and need any help.

Thanks!

Reference: OpenStack Developer

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s