doug.hellmann at dreamhost
May 18, 2012, 1:49 PM
Post #5 of 8
On Fri, May 18, 2012 at 3:08 PM, Sean Dague <sdague [at] linux>wrote:
Re: RFC - dynamically loading virt drivers
[In reply to]
> On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:
>> So we already have plugabillity by just specifying a different
>> compute_driver config option. I don't like that we defer another level in
>> compute and call get_connection. IMO the best cleanup would be to remove
>> the get_connection altogether and just construct the driver directly based
>> on compute_driver.
>> The main issue with changing this is breaking existing installs.
>> So I guess this would be my strategy:
>> a) remove get_connection from the drivers (and just have it construct the
>> 'connection' class directly)
>> b) modify the global get_connection to construct the drivers for
>> backwards compatibilty
>> c) modify the documentation to suggest changing drivers by specifying the
>> full path to the driver instead of connection_type
>> d) rename the connection classes to something reasonable representing
>> drivers (libvirt.driver:LibvirtDriver(**) vs libvirt.connection.**
>> e) bonus points if it could be done with a short path for ease of use
>> (compute_driver=libvirt.**LibvirtDriver vs compute_driver=nova.virt.**
> On point c), is the long term view that .conf options are going to specify
> full class names? It seems like this actually gets kind of confusing to
> What are your thoughts on the following approach, which is related, but a
> little different?
> a) have compute_driver take a module name in nova.virt. which is loaded
> with some standard construction method that all drivers would implement in
> their __init__.py. Match all existing module names to connection_type names
> current in use. Basically just jump to e, but also make all drivers conform
> some factory interface so "libvirt" is actually enough to get you
Andrew Bogott is working on a common plugin architecture. Under that system
plugins will have well-known, but short names and be loaded using
setuptools entry points (allowing them to be named independently of their
code/filesystem layout and packaged and installed separately from
nova). Could the drivers be loaded from these plugins?
> b) if compute_driver is not specified, use connection_type, but spit out a
> deprecation warning that the option is going away. (Removed fully in G).
> Because compute_drivers map to existing connection_types this just works
> with only a little refactoring in the drivers.
> c) remove nova/virt/connection.py
> The end result is that every driver is a self contained subdir in
> * 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).
>> Generally breakage like this is due to some global state that is not
>> cleaned up, so if FakeConnection is caching globally, then this could
> It is keeping global state, I'll look at fixing that independently.
> Sean Dague
> IBM Linux Technology Center
> email: sdague [at] linux
> alt-email: sldague [at] us
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>