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)
