Grokking OpenStack

OpenStack - little pieces

Who Are You and What Are You Going to Do?

This is the post in which I discuss how I set up a debugger to work for me with OpenStack, at least in the development environment. I like to be able to ask the code what object it is using, what the type of object is and what are the attributes. I always feel better when I can dialog directly with the code, no one knows better what is happening, and I dislike guessing since I am usually wrong. Better to ask, I find.

The first thing I had to do was select a debugger. I went with pdb, the python debugger that comes with python, simply because it was the easiest. I knew I needed to get the debugger working with OpenStack and I felt that the integration step would be my trickiest part so I elected for the simplest version of a debugger I could find and it appears that my decision to go with pdb was the right decision for me.

Then I had to learn how to use the debugger in a vanilla set-up. Since I didn’t know how the python debugger worked before I began, I spent some time with a few tutorial blog posts and am glad that I did. First I went here to go through the debugging A B C’s. I found it to be an easy tutorial and a great introduction. This tutorial showed me how to drop into the debugger by calling both the debugger and a file name from the command line.

I knew I wanted to access the debugger from the console so this was a great next tutorial. It creates a class in a file and then calls an instance of the class from the console with pdb.run(). It also calls the debugger after an exception with pdb.pm(). I liked the look of pdb.pm() since it could be invoked after an error or exception but every time I tried it, regardless of the pdb command I used, the debugger exited rather than stepping through the code. Initially I thought it was due to a mistake I made, but after further investigation I now believe that this seems to be the intended action of pdb.pm() though I have no idea why.

So while the second tutorial was helpful to show me that using the debugger from the console/interpreter was possible, I didn’t have the exact syntax I needed for my situation. Next I worked with this tutorial, rather long but for my purposes it gave me what I needed. The first part was the most helpful for me, I found the code for the last exercise - the advanced portion - didn’t match the output the tutorial displayed. I tried to locate the author but was unsuccessful.

So I decided to go with pdb import at the top of the file I wanted to start to step through and pdb.set_trace() at the location in the code where I wanted to drop into the debugger. Look at line #7 and line #43 in the code below. Line #44 was the beginning of the code I edited, which I wanted to evaluate, so I placed pdb.set_trace() on the line prior.

Next I needed to create an instance of novaclient in the python console. So I opened a console in my OpenStack development environment, imported the class for the client and created an instance.
python
import novaclient.v1_1.client
client = novaclient.v1_1.client.Client('admin', '<admin_password>', 'admin', 'http://50.56.25.223:5000/v2.0') Your ip will be different than mine but :5000/v2.0 should work for you, that is until it changes. So check the date on this blog post.

Then I requested the client fetch me an image by passing in the id of an existing image, which I had gotten with nova image-list earlier.
client.images.get('9e44f0ee-083d-40a4-804c-534d66fb15ac')

Now without pdb.set_trace() in the images.py code, the output to client.images.get(image id) is something like this:
<Image: cirros-0.3.0-x86_64-uec>

But with pdb.set_trace() in the images.py file, I got:

… and I’m in the debugger. Which was my goal.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

Comments