<br><br><div class="gmail_quote">On Fri, May 18, 2012 at 3:08 PM, Sean Dague <span dir="ltr"><<a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/17/2012 06:38 PM, Vishvananda Ishaya wrote:<br>
><br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
The main issue with changing this is breaking existing installs.<br>
<br>
So I guess this would be my strategy:<br>
<br>
a) remove get_connection from the drivers (and just have it construct the 'connection' class directly)<br>
b) modify the global get_connection to construct the drivers for backwards compatibilty<br>
c) modify the documentation to suggest changing drivers by specifying the full path to the driver instead of connection_type<br>
d) rename the connection classes to something reasonable representing drivers (libvirt.driver:LibvirtDriver(<u></u>) vs libvirt.connection.<u></u>LibvirtConnection)<br>
e) bonus points if it could be done with a short path for ease of use (compute_driver=libvirt.<u></u>LibvirtDriver vs compute_driver=nova.virt.<u></u>libvirt.driver.LibvirtDriver)<br>
</blockquote>
<br></div>
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.<br>
<br>
<br>
What are your thoughts on the following approach, which is related, but a little different?<br>
<br>
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()<br>
</blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
c) remove nova/virt/connection.py<br>
<br>
The end result is that every driver is a self contained subdir in nova/virt/DRIVERNAME/.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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).<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br></div>
It is keeping global state, I'll look at fixing that independently.<div class="im HOEnZb"><br>
<br>
-Sean<br>
<br>
-- <br>
Sean Dague<br>
IBM Linux Technology Center<br>
email: <a href="mailto:sdague@linux.vnet.ibm.com" target="_blank">sdague@linux.vnet.ibm.com</a><br>
alt-email: <a href="mailto:sldague@us.ibm.com" target="_blank">sldague@us.ibm.com</a><br>
<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/<u></u>ListHelp</a><br>
</div></div></blockquote></div><br>