openstack team mailing list archive

[Akira Yoshiyama <akirayoshiyama@xxxxxxxxx>]

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" <sdague@xxxxxxxxxxxxxxxxxx>:

> 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@xxxxxxxxxxxxxxxxxx
> alt-email: sldague@xxxxxxxxxx
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>