Open Stack

On May 17, 2012, at 1:52 PM, Sean Dague wrote:
> 
> 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.

-1 to LazyPluggable

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)

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

Vish