[openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

Ian Wells ijw.ubuntu at cack.org.uk
Mon Jun 8 18:00:29 UTC 2015


Hey Gary,

Sorry for being a little late with the followup...

Concerns with binding type negotiation, or with the scripting?  And could
you summarise the concerns, for those of us that didn't hear them?
-- 
Ian,

On 2 June 2015 at 07:08, Gary Kotton <gkotton at vmware.com> wrote:

>  Hi,
> At the summit this was discussed in the nova sessions and there were a
> number of concerns regarding security etc.
> Thanks
> Gary
>
>   From: Irena Berezovsky <irenab.dev at gmail.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Tuesday, June 2, 2015 at 1:44 PM
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] Progressing/tracking work on libvirt
> / vif drivers
>
>   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
>>
>>
>
> __________________________________________________________________________
> 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/20150608/0d8131f5/attachment.html>


More information about the OpenStack-dev mailing list