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 <gkot...@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....@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Tuesday, June 2, 2015 at 1:44 PM > To: OpenStack List <openstack-dev@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.ubu...@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.jer...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev