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