<div dir="ltr"><div><div>VIF plugging, but not precisely libvirt VIF plugging, so I'll tout this to a hopefully interested audience. <br><br>At the summit, we wrote up a spec we were thinking of doing at [1]. It actually proposes two things, which is a little naughty really, but hey.<br><br>Firstly we propose that we turn binding into a negotiation, so that Nova can offer binding options it supports to Neutron and Neutron can pick the one it likes most. This is necessary if you happen to use vhostuser with qemu, as it doesn't work for some circumstances, and desirable all around, since it means you no longer have to configure Neutron to choose a binding type that Nova likes and Neutron can choose different binding types depending on circumstances. As a bonus, it should make inter-version compatibility work better.<br><br></div>Secondly we suggest that some of the information that Nova and Neutron currently calculate independently should instead be passed from Neutron to Nova, simplifying the Nova code since it no longer has to take an educated guess at things like TAP device names. That one is more contentious, since in theory Neutron could pass an evil value, but if we can find some pattern that works (and 'pattern' might be literally true, in that you could get Nova to confirm that the TAP name begins with a magic string and is not going to be a physical device or other interface on the box) I think that would simplify the code there.<br><br></div>Read, digest, see what you think. I haven't put it forward yet (actually I've lost track of which projects take specs at this point) but I would very much like to get it implemented and it's not a drastic change (in fact, it's a no-op until we change Neutron to respect what Nova passes).<br><div><div><br>[1] <a href="https://etherpad.openstack.org/p/YVR-nova-neutron-binding-spec">https://etherpad.openstack.org/p/YVR-nova-neutron-binding-spec</a> <br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 June 2015 at 10:37, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/06/15 17:45, Neil Jerram wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Many thanks, John & Dan. I'll start by drafting a summary of the work<br>
that I'm aware of in this area, at<br>
<a href="https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work" target="_blank">https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work</a>.<br>
</blockquote>
<br></span>
OK, my first draft of this is now there at [1]. Please could folk with VIF-related work pending check that I haven't missed or misrepresented them? Especially, please could owners of the 'Infiniband SR-IOV' and 'mlnx_direct removal' changes confirm that those are really ready for core review? It would be bad to ask for core review that wasn't in fact wanted.<br>
<br>
Thanks,<br>
Neil<br>
<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work" target="_blank">https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work</a><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>