Open Stack

On Wed, Jul 23, 2014 at 10:52:54AM -0700, Dan Smith wrote:
> > 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
> 
> There are lots of them. We've had a bit of a background task running to
> remove them when possible/convenient and try to avoid adding new ones.
> I'm not opposed to aggressively removing them for sure, but it wouldn't
> be super high on my priority list. However, I definitely don't want to
> slide backwards when we have one already marked for removal :)
> 
> > 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.
> 
> I don't think there's any reason not to do that in nova itself, is
> there? Virt drivers are large, so maybe making an exception for that
> plug point makes sense purely for our own test efforts. However, for
> something smaller like you mention, I don't see why we need to keep
> them, especially given what it advertises (IMHO) to people.

The main reason for the plugin points I see is for vendors wishing to
ship custom out of tree extensions to their own customers/users without
sending them upstream, or before they've been released upstream. I don't
have much idea if this is a common thing vendors do though, as opposed
to just patching nova and giving their downstream consumers the entire
nova codebase instead of just a single extension file.

> > 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.
> 
> I can't really speak for "we", but certainly _I_ don't want to support
> that model. I think it leads to people thinking they can develop drivers
> for things like this out of tree permanently, which I'd really like to
> avoid.

FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we arbitrarily change
it during development any time we need to. The latter is not a serious
or practical view right now though given our out of tree Docker/Ironic
drivers. I'm just concerned that we've had these various extension
points exposed for a long time and we've not clearly articulated
that they are liable to be killed off (besides marking vif_driver
as deprecated)

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