Open Stack

On 23 July 2014 10:52, Dan Smith <dms at danplanet.com> wrote:

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

We should encourage new developers to use a new binding_type, rather than
continue with vif_driver substitution.  Replacing the generic VIF driver
basically loses all the nice binding_type support implemented there, when
what we actually want to do is say 'here is another VIF type, and here is a
binding type value you will see when you should be using it'.  An argument,
I think, for coming up with a mechanism in K that allows that to happen
with a little bit of config that isn't as manky as complete vif_driver
substitution and one that doesn't require nova and neutron config to be
precisely in lockstep (which was always the problem with vif_driver and why
the generic VIF driver was developed originally).  With that in mind I
would, absolutely, agree with deprecating the vif_driver setting.

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

I sympathise that we shouldn't expose any more interfaces to abuse than we
have to - not least because those interfaces then become frozen and hard to
change - but I think you need a stronger argument here.  It is useful to
have out of tree drivers for this stuff while people experiment, and
perhaps also in production systems.  It's clear by the variety of drivers
and their increasing number that we are still experimenting with VIF
plugging possibilities.  There's quite a lot of ways that you can attach a
VIF to a VM, and just because we happen to support a handful doesn't mean
to say we've provided every option.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/48936d8d/attachment.html>