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<mailto:irenab....@gmail.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, June 2, 2015 at 1:44 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto: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<mailto: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<mailto: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://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://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
