<p>Hi,</p>
<p>FYI, I have a patch for nova-cactus to import only one virt driver.<br>
<a href="http://www.debian.or.jp/~yosshy/nova-cactus-patches/1004.txt">http://www.debian.or.jp/~yosshy/nova-cactus-patches/1004.txt</a></p>
<p>Regards,<br>
Akira Yoshiyama</p>
<div class="gmail_quote">2012/05/18 6:12 "Sean Dague" <<a href="mailto:sdague@linux.vnet.ibm.com">sdague@linux.vnet.ibm.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rationale: nova loads drivers for various subsystems in very different ways, and not all of them are truly dynamic (i.e. a new driver could be fully self contained and not have to change a core source code file or monkey patch to load itself). I'd like to get all the driver plug points fully dynamic, and eventually a common pattern and loading mechanism is used on all of them, from a consistency perspective.<br>

<br>
I've got a first attempt at refactoring the nova.virt.connection module to stop having a pre-defined list of virt drivers as strings, and instead load modules dynamically using the the nova.openstack.commons.<u></u>importutils. This is in a branch on github - <a href="https://github.com/sdague/nova" target="_blank">https://github.com/sdague/nova</a><br>

<br>
The changed files are:<br>
git diff master | diffstat -w 20<br>
 tests/test_virt_driver_loader.<u></u>py |   54 ++++++++++<br>
 utils.py                         |    3<br>
 virt/connection.py               |   51 ++-------<br>
 virt/fake.py                     |    4<br>
 virt/libvirt/__init__.py         |    1<br>
 5 files changed, 75 insertions(+), 38 deletions(-)<br>
<br>
This passes the unit test battery on fake and libvirt drivers (* on fake) Because the strings passed to connection_type do map to module names, this shouldn't cause any issues with existing configurations.<br>
<br>
The xenapi and vmwareapi modules probably just need a similar __init__.py addition to make get_connection available on module load. Baremetal will be slightly more work (but not much) because it had some additional setup in nova/virt/connection.py.<br>

<br>
What I'm mostly looking for is comments on approach. Is importutils the prefered way to go about this (which is the nova.volume approach) now, or should this be using utils.LazyPluggable as is in nova.db.api, or some other approach entirely? Comments, redirections, appreciated.<br>

<br>
* one test fails for Fake in test_virt_drivers, but only when it's run as the full unit test, not when run on it's own. It looks like it has to do with FakeConnection.instance() caching, which actually confuses me a bit, as I would have assumed one unit test file couldn't affect another (i.e. they started a clean env each time).<br>

<br>
        -Sean<br>
<br>
-- <br>
Sean Dague<br>
IBM Linux Technology Center<br>
email: <a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a><br>
alt-email: <a href="mailto:sldague@us.ibm.com" target="_blank">sldague@us.ibm.com</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/<u></u>ListHelp</a><br>
</blockquote></div>