On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:
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)
+1
-jay
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
