Installing Latest Vagrant and Virtualbox version on Ubuntu 12.04

Recently I was trying to set up a vagrant tool on my laptop which runs Ubuntu 12.04 and realized that apt-get install gets me Version: 1.0.1 of Vagrant and 4.1 of virtualbox. But the tool needed a more recent version of both. So here are the steps I followed to get a more recent version of both working on my system:

Virtual Box:

I mostly followed the instructions on, added a few gotchas I picked on the way.

  • First check if you have an existing version of virtualbox running. Couple of ways of checking this include dpkg -s virtualbox  and ps -aux| grep virtualbox. If yes, you need to remove it completely by killing the process and purging the repository.   sudo apt-get purge virtualbox                                                                               pkill virtualbox
  • Add deb precise contrib to /etc/apt/sources.list
  • Download and register the key                                                                               wget -q -O- | sudo apt-key add -
  • Run update and get the required version of virtual box                                              sudo apt-get update                                                                                                      sudo apt-get install virtualbox-4.3
  • Ubuntu/Debian users might want to install the dkms package to ensure that the VirtualBox host kernel modules (vboxdrvvboxnetflt and vboxnetadp) are properly updated if the linux kernel version changes during the next apt-get upgrade.         sudo apt-get install dkms


Once virtualbox is installed, the next step is installing Vagrant. The instructions I followed are based off of this link, but the point to remember is to steer away from any virtualbox or linux headers related command, because that will undo all the setup done in the first half of the tutorial.

  • Go to the vagrant downloads page and download the version of vagrant you would like to install or use wget for the same.             wget
  • Once the package is downloaded, the next step is installing it, making sure you have the right package name.                                                                                 dpkg -i vagrant_1.2.4_i686.deb

Voila! Your vagrant box is ready to use. You can test it by adding a precise box and trying to bring it up. The trick to the second part of the tutorial is keeping it simple and not to reconfigure virtual box or its headers using dpkg once the vagrant install is done, like most tutorials ask you to.

Let me know if you have any questions or face any difficulties.

My experiences contributing to Twisted

I have been contributing to OpenStack for more than a year and have given a couple of talks with different people on contributing to OpenStack[1][2]. What I found while helping people contribute to OpenStack was one of the biggest hurdles to contributing to open source for people was the getting started phase – the logins to be created, documents to be signed, how to pick the first easy bug, etc. OpenStack has a lot of great documentation and resources to help new comers with the same, and in fact has an irc channel dedicated for the sole purpose of welcoming new comers[3].

Last weekend, I decided that it was time to get out of my comfort zone and experience what it was like to get started with an open source project all over again. I had heard lot of great things about Twisted[4], and had been playing around with a bit, so it was not a difficult choice.

Twisted, like OpenStack has a lot of great documentation on how to get started contributing. But like any new project, it takes a little while to get accustomed to the new terminology being used. Twisted has lots of getting started links , which is great but sometimes can be a little overwhelming to a new comer(like any other project again). Below are the steps I followed to getting started, with the help of the extremely helpful #twisted-dev community.

Signing up

Twisted is *very simple* to get signed up with. Just create a login and viola! you are ready to create tickets and submit patches. So I went ahead and created my login.

Finding a bug

Next step was for me to pick an easy bug/task to work on. I ended up clicking the View Tickets link on the twisted webpage and mulled over a little about Active tickets vs Unassigned tickets and how to find the low hanging fruit tickets. In twisted, the tickets have keywords, and the key to finding the low hanging fruit is to search based on theeasy‘ keyword[5].

Having previous experience with python and working in open source helped me quickly locate an easy bug to work on. If you have not contributed to open source before, a quick tip is to pick a really simple bug for your first contribution. The first commit/patch is to help you understand the process that open source project follows. I went ahead and picked ticket 6785 which was to remove a deprecated function and assigned myself to the ticket to express my intent on working on the ticket.

Working with the codebase

After picking the ticket, it was time to start hacking. I have been predominantly working with github for past few years and all the Twisted instructions were svn based. They did have a page for github users, but I was in for the authentic experience, so I stuck to using svn :) There are a number of plugins in svn to help make the process easier, but I decided to keep my first experience simple. I followed the step by step instructions in contributors documentation. This was the next point where I experienced a significant difference in the contribution process between OpenStack and Twisted. OpenStack uses gerrit[6] for reviews and submitting patches and in Twisted you directly upload the patches as files.

Submitting a patch

So I went ahead and uploaded my patch file to the ticket.  The patchsets have their own naming convention and they should be assigned to a branch (more details in the contributing to Twisted link). An important point is while specifying your branch name it is essential to specify the branches path along with the name of your branch. For example, the name of the branch in my ticket was : branches/remove-closeStdin-6785. Then the tests are run against the branch your patch is in.  Like OpenStack has Jenkins[7] to run tests, Twisted has BuildBot[8] to run the tests on the patch submitted. By talking to the developers in the #twisted-dev channel I discovered that only a core contributor of Twisted could trigger the tests against the branch.

One feature which I thought was pretty neat in Twisted was the news files[9]. While working on my first patch, which was to remove a deprecated function, I found out that Twisted has news files. In case you are adding/removing/changing a functionality, information about it goes in the news folder, which is later compiled and sent as a synopsis of updates to the members of the community.

Waiting for reviews

Right now I have submitted the third patchset for my first bug and I am waiting for the reviewers to take a look at it. One point to note is that if you want your patch to get reviewed, you need to add ‘review’ as a keyword to your ticket.

I hope to update this post with more details about how the patch gets reviewed and merged once I have completed the process. Watch this space for more :)

And thanks to the Twisted community for being great with the new comers!










Seven lesser known tips for Idiomatic Python

If you have been programming in python, you must have often heard phrases like “code like a pythonista” or “idiomatic python”. These phrases basically try to emphasize on “readability counts” philosophy in the Zen of Python. There have been several articles on idiomatic python, but below are seven lesser known tips on writing idiomatic python:

1. Use else to execute code after a for loop ends

>>> for zipcode in zipcodes:
...    if len(zipcode) > 5:
...        print "Invalid length"
... else:
...    print "Valid length"
Valid length

2. Use comprehensions

List comprehensions are very popular, but few people know about dict comprehensions and set comprehensions.

List Comprehension
>>> name_dict = {name.fname : name.lname for name in names if name.lname}

Set Comprehension
>>> name_set = {name.fname for name in names if name.lname}

3. Define __str__ in a class to show a human readable representation of the class

>>> class Name:
...     def __init__(self, name):
... = name
...     def __str__(self):
...         return "This class represents a Name"
>>> name = Name('john')
>>> print name
This class represents a Name

4. Use a generator to lazily load infinite sequences

5. Use _ as a place holder for data in a tuple that should be ignored

(instance_name, instance_size, _) = get_instance_info(instance_uuid)

6. Use partial to fixate function variables

>>> def long_name(first_name, middle_name, last_name):
...     print first_name, middle_name, last_name
>>> short_name = functools.partial(long_name, 'john')
>>> short_name('jim', 'jr')

7. Use zip and izip to help loop over two collections

>>> number = [1, 2, 3]
>>> number_name = ['one', 'two', 'three']
>>> for num, num_name in zip(number, number_name):
...     print num, num_name
1 one
2 two
3 three


[1] Writing Idiomatic Python
[2] Advice by Raymond Hettinger

Migration in devstack

I have been working on image sharing in glance. As a part of it, the code requires I write a new migration adding in a column in an existing table. Below are the steps on how to run test if your migration works using devstack:

1. sudo python install
This is important because Step 3, runs on packages built by this command.

2.sudo glance-manage version_control 0

3.sudo glance-manage db_sync

4.sudo restart glance-api

5.sudo restart glance-registry

6. Test your migration using various glance commands!

Contributing to OpenStack

My colleague, Alex, and I recently conducted a workshop on Contributing to OpenStack. In order to create a presentation deck for the workshop, I searched through several of the existing presentations, though they were very resourceful in their own ways, I could not find a one stop place for all the information I needed. I have embedded below the presentation I created for the workshop, hope you find it useful too.


OpenStack 101 Resources

In past few months, many people have asked me how to get started on contributing to OpenStack or about getting started with OpenStack guides. So instead of making this post about how to contribute to OpenStack, below is a culmination of various resources many people have found useful. If you have any other useful resources, feel free to leave links to them in the comments.

Other Misc resources:

FOSS Outreach Program for Women

Free and Open Source Software (FOSS) Outreach Program for Women(OPW) has been one of my main sources of inspiration to start blogging. Though the main objective of the program is to help get women introduced to the world of contributing to open source, I feel it is also a big learning experience for the mentors of the program.

When Anne Gentle asked me if I would like to be a mentor on the OpenStack project for the FOSS OPW, the teacher in me got all charged up and enthusiastic. It has been only a few weeks since the application phase of the program has begun, but I have already got to meet several brilliant women from all walks of life. The rush the applicants get from submitting their first patch to OpenStack, does not die subsequently, but in fact they go on to inspire other applicants and guide them through the process of submitting their first patch as well. Anita and Shruthi, applicants for the OPW program penned down their experiences with OpenStack and it has inspired several others, including me, to give back in as many different ways as possible.