Hi, FYI, I have a patch for nova-cactus to import only one virt driver. http://www.debian.or.jp/~yosshy/nova-cactus-patches/1004.txt
Regards, Akira Yoshiyama 2012/05/18 6:12 "Sean Dague" <[email protected]>: > 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: [email protected] > alt-email: [email protected] > > > ______________________________**_________________ > Mailing list: > https://launchpad.net/~**openstack<https://launchpad.net/~openstack> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~**openstack<https://launchpad.net/~openstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
