Getting started hacking on OpenStack Nova

Posted: March 9th, 2012 | Filed under: Fedora, libvirt, OpenStack, Virt Tools | Tags: , , , | 5 Comments »

In recent months I have spent more of my time working on projects immediately above/related to the core libvirt library, such as libvirt-glib, libosinfo and virt-sandbox. To that list I have now added OpenStack, where my goal is to ensure that the libvirt driver is following all the best practices and start to take advantage of libosinfo for optimizing virtual hardware configuration. I’m familiar with hacking on python so that’s no big issue, but what is new about OpenStack is dealing with Gerrit.  For the sake of reference, here were the steps I went through on Fedora 16 for my first patch (a tweak to the tools/ file)

  1. Get the initial Nova GIT checkout
    $ mkdir $HOME/src/cloud
    $ cd $HOME/src/cloud
    $ git clone git://
    $ cd nova
  2. Install some basic pre-reqs, and ensure python-distutils-extra is not present since that conflicts with part of the openstack build system
    $ sudo yum install gcc python-pep8 python-virtualenv m2crypto libvirt libvirt-python libxslt-devel libxml2-devel
    $ sudo yum remove python-distutils-extra
  3. Visit the OpenStack Gerrit Website, and follow ‘Sign In’ link which redirects to LaunchPad for authentication
  4. Back on Gerrit site, now signed in, follow ‘Settings’ link, select ‘SSH Public Keys’ page, and paste your SSH public key (eg contents of $HOME/.ssh/
  5. Test SSH connectivity from the CLI
    $ ssh -p 29418
    The authenticity of host '[]:29418 ([]:29418)' can't be established.
    RSA key fingerprint is ee:2f:ac:1b:f8:25:d0:39:be:55:02:c7:76:5e:39:53.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[]:29418,[]:29418' (RSA) to the list of known hosts.
    **** Welcome to Gerrit Code Review ****
    Hi Daniel Berrange, you have successfully connected over SSH.
    Unfortunately, interactive shells are disabled.
    To clone a hosted Git repository, use:
    git clone ssh://
    Connection to closed.
  6. Install commit hook to ensure ‘ChangeId’ fields get added to your commits
    $ scp -p -P 29418 .git/hooks/
  7. Add the gerrit remote to GIT config
    $ git remote add gerrit ssh://
  8. Start a new branch for your work
    $ git checkout -b venv-install-fixes
  9. Make whatever code changes you need todo
    $ vi tools/
    $ git add -u
    (Don't forget to add yourself to Authors if this is your first change)
  10. Commit the changes, checking the commit message gets a ‘Change-Id’ line added just prior to the signed-off-by line
    $ git commit -s
    $ git show
    commit fd682a28fb4591c65f20129d4bfb4eccf1232cb8
    Author: Daniel P. Berrange <>
    Date: Thu Jan 5 13:15:15 2012 +0000
    Tell users what is about to be installed via sudo
    Rather than just giving users the sudo password prompt immediately,
    actually tell them what is about to be installed, so they know what
    privileged action is being attempted.
    Change-Id: Ic0c1de812be119384753895531a008075b13494e
    Signed-off-by: Daniel P. Berrange <>

    If the commit is fixing a OpenStack bug, then the commit message should include a line “BugXXXX” where XXXX is the bug number. Gerrit uses this to link to the bug tracker

  11. Run the unit test suite, and the python pep8 syntax test suite; Be prepared to wait a long time
    $ ./
    $ ./ --pep8
  12. Send the changes to Gerrit for review
    $ git push gerrit HEAD:refs/for/master
  13. Wait for email notifications of review, or watch the OpenStack Gerrit Website.
  14. If problems are found by reviewers, or the automated smoke stack tests. Repeat steps 9->l;12, but use ‘git commit –amend’ to ensure you preserve the original “Change-Id” line in the commit message. This lets gerrit track followup patches.
  15. If everything passes review & testing, it will be automatically merged into master.

There is also a GIT plugin  “git review” available in the git-review RPM, which can provide syntactic sugar for step 12, but personally I don’t find it adds significant value to be worth my while using.

I can see the attraction of Gerrit, but I personally still prefer the practice of using git send-email for reviewing on mailing lists. My problems with Gerrit are

  • The email notifications sent out for new patches are almost worse than useless as an information source
  • While very pretty, the web UI for browsing the diffs is really quite cumbersome to use
  • Poor support for reviewing large patch series
  • Use of merge commits makes navigating GIT history cumbersome, forcing the use of the graphical gitk viewer tool