Open Stack

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.

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.importutils. This is in a branch on github - 
https://github.com/sdague/nova

The changed files are:
git diff master | diffstat -w 20
  tests/test_virt_driver_loader.py |   54 ++++++++++
  utils.py                         |    3
  virt/connection.py               |   51 ++-------
  virt/fake.py                     |    4
  virt/libvirt/__init__.py         |    1
  5 files changed, 75 insertions(+), 38 deletions(-)

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.

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.

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.

* 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).

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com