OpenStack Development Process

Preface

OpenStack is a cloud computing project to provide an infrastructure as a service (IaaS). It is free open source software released under the terms of the Apache License. The project is managed by the OpenStack Foundation, a non-profit corporate entity established in September 2012 to promote OpenStack software and its community. More than 200 companies joined the project.
How you can understand that is large project with hundreds of developers, hundreds of thousands lines of code. This topic will make clear development process in OpenStack and how to push the code into OpenStack.

Start OpenStack development

1. Signing up for accounts:

The first thing you should do is signing up for LaunchPad account. LaunchPad is a web application and website that allows users to develop and maintain software, particularly open-source software. Launchpad is developed and maintained by Canonical Ltd. The OpenStack project uses LaunchPad for mailing list, blueprints, groups, bug tracking. Each OpenStack project will have a LaunchPad project.  You can create account here.

The next you should signing up in Gerrit. Gerrit is a free, web-based team software code review tool. Software developers in a team can review each other’s modifications on their source code using a Web browser and approve or reject those changes. It integrates closely with Git, a distributed version control system. To interact with Gerrit you need to set SSH key. Because all Gerrit commands are using SSH protocol and the host port is 29418. A user can access Gerrit’s Git repositories with SSH or HTTP protocols. The user must have registered in Gerrit and a public SSH key before any command line commands can be used.

2. Communication tools: 

You should be on OpenStack’s mailing list and also on your OpenStack project’s mailing list. It’s necessary to take part in discussions about code development, project design etc. You can subscribe to mailing list according this instruction.

Also for quick answers you can use the IRC channels. It can be questions about how to work with particular methods or about why tests fail. Every week you should take part on IRC meeting of your project where you can discuss some release detail or your own bugs etc. Information about IRC channels you can find here.

3. Setting up development environment:

You can develop on any system you want but the most used and the most comfortable for this aim is Ubuntu. The first thing you need it is Git. In software development, Git is a distributed revision control and source code management (SCM) system with an emphasis on speed. You need Git to pull and push code into Gerrit.

The next step is DevStack. DevStack’s mission is to provide and maintain tools used for the installation of the central OpenStack services from source (git repository master, or specific branches) suitable for development and operational testing. It also demonstrates and documents examples of configuring and running services as well as command line client usage.

git clone git://github.com/openstack-dev/devstack.git
cd devstack; ./stack.sh

Now you can get an Openstack project:

git clone https://git.openstack.org/openstack/ceilometer

This topic not about development of ceilometer so let skip it. Let image that you already have a complete code.
You need install a pip. Pip is a tool for installing and managing Python packages.

sudo apt-get install python pip

Mostly you need pip for install a tox.

sudo pip install tox

OpenStack has a lot of projects. For each project, the OpenStack Jenkins needs to be able to perform a lot of tasks. If each project has a slightly different way to accomplish those tasks, it makes the management of a consistent testing infrastructure very difficult to deal with. Additionally, because of the high volume of development changes and testing, the testing infrastructure has to be able to pre-cache artifacts that are normally fetched over the internet. To that end, each project should support a consistent interface for driving tests and other necessary tasks.

  • tox -epy26 – Unit tests for python2.6
  • tox -epy27 – Unit tests for python2.7
  • tox -epep8 –  pep8 checks

If all tests are running you can already pull the code into Gerrit.

4.Publication code:

Simply running git review should be sufficient to push your changes to Gerrit, assuming your repository is set up as described above, you don’t need to read the rest of this section unless you want to use an alternate workflow.

If you want to push your changes without using git-review, you can push changes to gerrit like you would any other git repository, using the following syntax (assuming “gerrit” is configured as a remote repository):

git push gerrit HEAD:refs/for/$BRANCH[/$TOPIC]

Where $BRANCH is the name of the Gerrit branch to push to (usually “master”), and you may optionally specify a Gerrit topic by appending it after a slash character.

If you want to commit changes: Git commit messages should start with a short 50 character or less summary in a single paragraph. The following paragraph(s) should explain the change in more detail.

If your changes addresses a blueprint or a bug, be sure to mention them in the commit message using the following syntax:

blueprint BLUEPRINT
Closes-Bug: ####### (Partial-Bug or Related-Bug are options)

For example:
Adds keystone support

...Long multiline description of the change...

Implements: blueprint authentication
Closes-Bug: #123456
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657

5.Code review: 

Automatic testing occurs and the results are displayed. Reviewers comment in the comment box or in the code itself.

If someone leaves an in-line comment, you can see it from expanded “Patch Set.” “Comments” column shows how many comments are in each file. If you click a file name that has comments, the new page shows a diff page with the reviewer’s name and comments. Click “Reply” and write your response. It is saved as a draft if you click “Save.” Now, go back to the page that shows a list of patch sets and click “Review,” and then, click “Publish comments.”

If your code is not ready for review, click “Work in Progress” to indicate that a reviewer does not need to review it for now. Note that the button is invisible until you login the site.

 

Leave a Reply

Your email address will not be published. Required fields are marked *