cbda169377
inadvertently blocking the reactor thread. The reworking puts all calls to XenAPI on background threads, so that they won't block the reactor thread. Long-lived operations (VM start, reboot, etc) are invoked asynchronously at the XenAPI level (Async.VM.start, etc). These return a XenAPI task. We relinquish the background thread at this point, so as not to hold threads in the pool for too long, and use reactor.callLater to poll the task. This combination of techniques means that we don't block the reactor thread at all, and at the same time we don't hold lots of threads waiting for long-running operations. There is a FIXME in here: get_info does not conform to these new rules. Changes are required in compute.service before we can make get_info non-blocking.
The Choose Your Own Adventure README for Nova: You have come across a cloud computing fabric controller. It has identified itself as "Nova." It is apparent that it maintains compatability with the popular Amazon EC2 and S3 APIs. To monitor it from a distance: follow @novacc on twitter To tame it for use in your own cloud: read http://nova.openstack.org/getting.started.html To study its anatomy: read http://nova.openstack.org/architecture.html To disect it in detail: visit http://code.launchpad.net/nova To taunt it with its weaknesses: use http://bugs.launchpad.net/nova To watch it: http://hudson.openstack.org To hack at it: read HACKING To laugh at its PEP8 problems: http://hudson.openstack.org/job/nova-pep8/violations To cry over its pylint problems: http://hudson.openstack.org/job/nova-pylint/violations