<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 July 2014 10:52, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> What is our story for people who are developing new network or<br><div class="">
> storage drivers for Neutron / Cinder and wish to test Nova ? Removing<br>
> vif_driver and volume_drivers config parameters would mean that they<br>
> would have to directly modify the existing Nova libvirt<br>
> <a href="http://vif.py/volume.py" target="_blank">vif.py/volume.py</a> codefiles.<br>
><br>
> This isn't neccessarily bad because they'll have to do this anyway<br>
> if they want to actually submit it to Nova.<br>
<br>
</div>I don't think there's any reason not to do that in nova itself, is<br>
there? Virt drivers are large, so maybe making an exception for that<br>
plug point makes sense purely for our own test efforts. However, for<br>
something smaller like you mention, I don't see why we need to keep<br>
them, especially given what it advertises (IMHO) to people.<br></blockquote><div><br></div><div class="">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.<br>


<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can't really speak for "we", but certainly _I_ don't want to support<br>
that model. I think it leads to people thinking they can develop drivers<br>
for things like this out of tree permanently, which I'd really like to<br>
avoid.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.<br>

</div>-- <br></div><div class="gmail_quote">Ian.<br></div></div></div>