openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, May 18, 2012 at 3:08 PM, Sean Dague <sdague@xxxxxxxxxxxxxxxxxx>wrote:

> 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.**
>> LibvirtConnection)
>> 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.**
>> libvirt.driver.LibvirtDriver)
>>
>
> 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
> admins.
>
>
> 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
> nova.virt.libvirt.connect()
>

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
> nova/virt/DRIVERNAME/.
>
>
>  * 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
>> happen.
>>
>
> It is keeping global state, I'll look at fixing that independently.
>
>
>        -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>
>