Open Stack

VIF plugging, but not precisely libvirt VIF plugging, so I'll tout this to
a hopefully interested audience.

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.

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.

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.

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

[1] https://etherpad.openstack.org/p/YVR-nova-neutron-binding-spec

On 1 June 2015 at 10:37, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:

> On 01/06/15 17:45, Neil Jerram wrote:
>
>  Many thanks, John & Dan.  I'll start by drafting a summary of the work
>> that I'm aware of in this area, at
>> https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.
>>
>
> 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.
>
> Thanks,
>         Neil
>
>
> [1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150602/3e42eaaf/attachment.html>