<br><br><div class="gmail_quote">On Tue, Jan 29, 2013 at 4:30 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> This led me to wonder if we could do the following: if the Quantum plugin<br>
> in use supports the vif-plugging extension, ignore the local vif-plugging<br>
> config and use the "universal driver" with the config from quantum<br>
> (probably while issuing a warning). I think it should be feasible in the<br>
> "H" release to make the vif-plugging extension mandatory for Quantum, at<br>
> which point, there would always be a warning for any user that specifies an<br>
> old-style vif-plugging option (assuming H-release was being used for Nova +<br>
> Quantum). Starting with H-series we would no longer document the<br>
> old-style vif-plugging options, and users would get warnings if they were<br>
> left-over in configs due to an upgrade, but nothing would break, because<br>
> they weren't required to specify a new type of vif-plugging.<br>
<br>
</div>Ah, you seem to be thinking that the 'libvirt_vif_driver' config parameter<br>
will go away completely. This is not my intention. I just want to have a<br>
situation where admins do not need to use it for any configuration using<br>
in-tree OpenStack components.<br></blockquote><div><br></div><div>Yup, I understand that that is what you are proposing. But I was thinking about the issue that everyone currently using Quantum will have to change their configuration by switching vif_plugging in order to take advantage of the Quantum API extensions in Havana. That just got me wondering if there could be a cleaner approach. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If someone develops a new Quantum plugin out of tree, and needs to also<br>
do some work on the Nova side to support that, we still need to have the<br>
'libvirt_vif_driver' parameter around.<br></blockquote><div><br></div><div>I understand the motivation, but in my experience, out-of-tree vif-drivers worked very poorly in practice, as subtle changes within nova would end up breaking those drivers without triggering unit test failures, since the drivers were out of tree (the Cisco plugin relied on such an out-of-tree driver and it seemingly was subject to frequent breakage). </div>
<div><br></div><div>So to play devil's advocate, if starting in "H", we allow the quantum vif-plugging extension to return all information needed for Nova to plug vifs, in what scenario would we rather have someone create an out-of-tree vif-plugging mechanism, rather than just return the data via their Quantum plugin? </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I don't want to have anything where we magically ignore the<br>
'libvirt_vif_driver' parameter in some scenarios - we should always<br>
honour that parameter. Just that with it configured to LibvirtGenericVIFDriver,<br>
99% of users will never need to touch it now.<br></blockquote><div><br></div><div>Yeah, I agree on the goal of having the LibvirtGenericVIFDriver as the default behavior, I'm must less convinced that in the long-term we'd even want to keep the vif-driver stuff around at all. Having Quantum automatically use the generic vif-driver behavior if the vif-plugging extension is in use seems to provide a smoother transition, and a cleaner and more simple system in the end. </div>
<div><br></div><div>Thanks, </div><div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>