Open Stack

Hi Ian,
I like your proposal. It sounds very reasonable and makes separation of
concerns between neutron and nova very clear. I think with vif plug script
support [1]. it will help to decouple neutron from nova dependency.
Thank you for sharing this,
Irena
[1] https://review.openstack.org/#/c/162468/

On Tue, Jun 2, 2015 at 10:45 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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
>>
>
>
> __________________________________________________________________________
> 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/37877e3e/attachment.html>