Open Stack

On Wed, Jul 23, 2014 at 10:09:37AM -0700, Dan Smith wrote:
> > I don't see an issue with allowing people to configure 3rd party impl
> > for the VIF driver, provided we don't claim that the VIF driver API
> > contract is stable, same way we don't claim virt driver API is stable.
> > It lets users have a solution to enable custom NIC functionality while
> > waiting for Nova to officially support it. If we did remove it, then
> > users could still subclass the main libvirt driver class and make
> > it use their custom VIF driver, so they'd get to the same place just
> > with an extra inconvenient hoop to jump through. So is it worth removing
> > vif_driver ?
> 
> In my opinion, we should (continue to) remove any of those plug points
> that we don't want to actually support as plugin interfaces. The virt
> driver plug point at least serves to allow us to develop and test
> drivers outside of the tree (ironic and docker, for example) before
> merging. The vif_driver (and others) imply that it's a plugin interface,
> when we have no intention of making it one, and I think we should nuke them.

If we're going to do that, then we should be consistent. eg there is a
volume_drivers parameter that serves the same purpose as vif_driver

What is our story for people who are developing new network or storage
drivers for Neutron / Cinder and wish to test Nova ? Removing vif_driver
and volume_drivers config parameters would mean that they would have to
directly modify the existing Nova libvirt vif.py/volume.py codefiles.

This isn't neccessarily bad because they'll have to do this anyway if
they want to actually submit it to Nova.

It is, however, notably different from what they can do today where they
can drop in a impl for their new Neutron/Cinder driver without having to
modify any existing Nova code directly. This could be a pain if they wish
to provide the custom driver to users/customers of the previous stable
Nova release while waiting for official support in next Nova release. It
sounds like you're explicitly saying we don't want to support that use
case though.

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 :|