[openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
ijw.ubuntu at cack.org.uk
Mon Jun 8 18:00:29 UTC 2015
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?
On 2 June 2015 at 07:08, Gary Kotton <gkotton at vmware.com> wrote:
> At the summit this was discussed in the nova sessions and there were a
> number of concerns regarding security etc.
> 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 . it will help to decouple neutron from nova dependency.
> Thank you for sharing this,
>  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 . 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).
>>  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
>>> OK, my first draft of this is now there at . 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.
>>>  https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev