Tip: Debugging tests in OpenStack

One easy way to debug tests in openstack using pdb, is to include the sentence:

import pdb; pbd.set_trace()

at the begining of the test is failing, and re-run it with the --nocapture option:

ghe@debian:glance(master)$ ./run_tests.sh -N glance.tests.functional.v1.test_api --nocapture

We test the following: ... > /home/ghe/github/openstack/glance/glance/tests/functional/v1/test_api.py(1170)test_delete_not_existing()
-> self.cleanup()
(Pdb) 


Happy sysadmin day!

Debian and OpenStack

In February I wrote:

"The major problem of Debian and OpenStack, is Debian itself. In a so fast moving project like OpenStack, having an "EveryThing-Ready-and-Included" release every two years is not viable for this scenario. In the case of OpenStack, Squeeze is too old to handle it the way it is right now (Too many things not directly related with OpenStack, like qemu-xen, python-modules, etc.,   should be backported to make it functional, and with just volunteer packagers, make it a not so viable option). In the other hand, the next release, is planned to 1Q 2013 (Wheezy being frozen in later June), so Essex release will be outdated and Folsom we be the stable release by then, and with G release knocking on the door (Essex is supposed to be a LTS release, supported by Canonical/Ubuntu until around April 2017so is not that bad). Solutions?  Forget about Squeeze, focus in Wheezy + Essex as an official release , and Folsom (or G release) as a back-ported option. The other option (not viable in a short term), is change the way Debian makes it releases, and try to have something more "componentized" (like Progeny tried to do some years ago) or "rolling-releases", so trending-topic these days.  Neither GNOME, OpenStack, LibreOffice, linux-kernel (just to name some) has a similar release cycle or core necessities to run in a system, so why try to release, prepare, stabilized everything at the same time no matter what's the status the upstream project is? (Just int he case of OpenStack, and supposing everything thing is going according the schedule, with a 6 month release cycle vs. 2 years in Debian + frozen period, when Wheezy is released, we are going to release an outdated version -essex (but LTS thanks to Canonical)-  when Folsom is 4 months old! and the new release coming in less than two months!) I agree this needs a lot of more development, but i think it's something that Debian should have to think about." 

Re-reading it, the situation is not that bad actually. We were lucky enough that the new Ubuntu LTS was released, and we can use the excuse of Essex being supported until 2017. But the key point is the same: "Debian is huge and slow, while OpenStack (and so many other projects) are really fast-moving"

Debian And OpenStack

In February I wrote:

"The major problem of Debian and OpenStack, is Debian itself. In a so fast moving project like OpenStack, having an "EveryThing-Ready-and-Included" release every two years is not viable for this scenario. In the case of OpenStack, Squeeze is too old to handle it the way it is right now (Too many things not directly related with OpenStack, like qemu-xen, python-modules, etc.,   should be backported to make it functional, and with just volunteer packagers, make it a not so viable option). In the other hand, the next release, is planned to 1Q 2013 (Wheezy being frozen in later June), so Essex release will be outdated and Folsom we be the stable release by then, and with G release knocking on the door (Essex is supposed to be a LTS release, supported by Canonical/Ubuntu until around April 2017so is not that bad). Solutions?  Forget about Squeeze, focus in Wheezy + Essex as an official release , and Folsom (or G release) as a back-ported option. The other option (not viable in a short term), is change the way Debian makes it releases, and try to have something more "componentized" (like Progeny tried to do some years ago) or "rolling-releases", so trending-topic these days.  Neither GNOME, OpenStack, LibreOffice, linux-kernel (just to name some) has a similar release cycle or core necessities to run in a system, so why try to release, prepare, stabilized everything at the same time no matter what's the status the upstream project is? (Just int he case of OpenStack, and supposing everything thing is going according the schedule, with a 6 month release cycle vs. 2 years in Debian + frozen period, when Wheezy is released, we are going to release an outdated version -essex (but LTS thanks to Canonical)-  when Folsom is 4 months old! and the new release coming in less than two months!) I agree this needs a lot of more development, but i think it's something that Debian should have to think about." 

Re-reading it, the situation is not that bad actually. We were lucky enough that the new Ubuntu LTS was released, and we can use the excuse of Essex being supported until 2017. But the key point is the same: "Debian is huge and slow, while OpenStack (and so many other projects) are really fast-moving"