Merge lp:~ewanmellor/nova/xenapi-concurrency-model into lp:~hudson-openstack/nova/trunk
Status: | Superseded |
---|---|
Proposed branch: | lp:~ewanmellor/nova/xenapi-concurrency-model |
Merge into: | lp:~hudson-openstack/nova/trunk |
Diff against target: |
326 lines (+163/-37) 1 file modified
nova/virt/xenapi.py (+163/-37) |
To merge this branch: | bzr merge lp:~ewanmellor/nova/xenapi-concurrency-model |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jay Pipes (community) | Approve | ||
Review via email: mp+32722@code.launchpad.net |
This proposal has been superseded by a proposal from 2010-08-17.
Description of the change
Rework virt.xenapi's concurrency model. There were many places where we were
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.
Really nice work, Ewan! No criticism at all from me! Feel free to uncomment the logging.debug() output, though. :)