Open Stack

On Tue, Jan 29, 2013 at 4:30 AM, Daniel P. Berrange <berrange at redhat.com>wrote:
>
>
> > This led me to wonder if we could do the following: if the Quantum plugin
> > in use supports the  vif-plugging extension, ignore the local
> vif-plugging
> > config and use the "universal driver" with the config from quantum
> > (probably while issuing a warning).  I think it should be feasible in the
> > "H" release to make the vif-plugging extension mandatory for Quantum, at
> > which point, there would always be a warning for any user that specifies
> an
> > old-style vif-plugging option (assuming H-release was being used for
> Nova +
> > Quantum).   Starting with H-series we would no longer document the
> > old-style vif-plugging options, and users would get warnings if they were
> > left-over in configs due to an upgrade, but nothing would break, because
> > they weren't required to specify a new type of vif-plugging.
>
> Ah, you seem to be thinking that the 'libvirt_vif_driver' config parameter
> will go away completely. This is not my intention. I just want to have a
> situation where admins do not need to use it for any configuration using
> in-tree OpenStack components.
>

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.


>
> If someone develops a new Quantum plugin out of tree, and needs to also
> do some work on the Nova side to support that, we still need to have the
> 'libvirt_vif_driver' parameter around.
>

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

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?


> So I don't want to have anything where we magically ignore the
> 'libvirt_vif_driver' parameter in some scenarios - we should always
> honour that parameter. Just that with it configured to
> LibvirtGenericVIFDriver,
> 99% of users will never need to touch it now.
>

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.

Thanks,

Dan




>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-             http://virt-manager.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc:|
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/32bfb862/attachment.html>