Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
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
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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
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.commailto:irenab@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 2, 2015 at 1:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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.ukmailto: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.commailto: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:unsubscribehttp://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:unsubscribehttp://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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
On 29 May 2015 at 18:32, Neil Jerram neil.jer...@metaswitch.com wrote: Hi all, Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is being somewhat driven by the etherpad at [2]. But this etherpad doesn't have a section for libvirt / vif driver changes. The log at [1] briefly touched on this, but moved on after noting that Dan PB had disbanded a libvirt subteam for lack of interest. Apologies, I am not nearly half way through writing up all that came out of the summit. A few nasty bugs in production kept me occupied last week, but I have got out of that now / fixed them, I hope. In the design summit session we said any group of people can self-organise and start proposing patches as ready to merge by that sub team, in here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking We agreed that if there were too many sub teams, we would ask the teams to join together. And I hope some subteams find each other on that etherpad, and organically decide its best to join forces. While we have established patterns of successful sub team collaborations (IRC meetings, bug tags, etc), feel free to do whatever works, assuming its aligned with the Open nature of our community (i.e. I expect code reviews to be done in gerrit, not using some internal communication channel. Even if you review face to face, I would appreciate you writing up the outcome in gerrit). So, what should folk interested in libvirt / vif work (including me) now do? I think the answer is that we should self-organize, then report to the next IRC on how we've done that, and I'm happy to lead that if no one else wants to - but is there someone else who should or wants to own this? In summary, yes please, sounds good. I would reach out to Dan, and the other folks who were active in those meetings, to see how it best makes sense to collaborate. Let me know if I can help connect you folks, but IRC usually works. Thanks, John __ 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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
On 01/06/15 14:23, Daniel P. Berrange wrote: On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote: On 29 May 2015 at 18:32, Neil Jerram neil.jer...@metaswitch.com wrote: Hi all, Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is being somewhat driven by the etherpad at [2]. But this etherpad doesn't have a section for libvirt / vif driver changes. The log at [1] briefly touched on this, but moved on after noting that Dan PB had disbanded a libvirt subteam for lack of interest. Apologies, I am not nearly half way through writing up all that came out of the summit. A few nasty bugs in production kept me occupied last week, but I have got out of that now / fixed them, I hope. In the design summit session we said any group of people can self-organise and start proposing patches as ready to merge by that sub team, in here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking We agreed that if there were too many sub teams, we would ask the teams to join together. And I hope some subteams find each other on that etherpad, and organically decide its best to join forces. While we have established patterns of successful sub team collaborations (IRC meetings, bug tags, etc), feel free to do whatever works, assuming its aligned with the Open nature of our community (i.e. I expect code reviews to be done in gerrit, not using some internal communication channel. Even if you review face to face, I would appreciate you writing up the outcome in gerrit). So, what should folk interested in libvirt / vif work (including me) now do? I think the answer is that we should self-organize, then report to the next IRC on how we've done that, and I'm happy to lead that if no one else wants to - but is there someone else who should or wants to own this? In summary, yes please, sounds good. I would reach out to Dan, and the other folks who were active in those meetings, to see how it best makes sense to collaborate. Let me know if I can help connect you folks, but IRC usually works. I'm mostly just lurking on IRC but keep an eye out on this mailing list for anything tagged with [nova]. So if there's any times my input is needed I should catch the mails as long as they're on the list. 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. Thanks, Neil __ 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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote: On 29 May 2015 at 18:32, Neil Jerram neil.jer...@metaswitch.com wrote: Hi all, Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is being somewhat driven by the etherpad at [2]. But this etherpad doesn't have a section for libvirt / vif driver changes. The log at [1] briefly touched on this, but moved on after noting that Dan PB had disbanded a libvirt subteam for lack of interest. Apologies, I am not nearly half way through writing up all that came out of the summit. A few nasty bugs in production kept me occupied last week, but I have got out of that now / fixed them, I hope. In the design summit session we said any group of people can self-organise and start proposing patches as ready to merge by that sub team, in here: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking We agreed that if there were too many sub teams, we would ask the teams to join together. And I hope some subteams find each other on that etherpad, and organically decide its best to join forces. While we have established patterns of successful sub team collaborations (IRC meetings, bug tags, etc), feel free to do whatever works, assuming its aligned with the Open nature of our community (i.e. I expect code reviews to be done in gerrit, not using some internal communication channel. Even if you review face to face, I would appreciate you writing up the outcome in gerrit). So, what should folk interested in libvirt / vif work (including me) now do? I think the answer is that we should self-organize, then report to the next IRC on how we've done that, and I'm happy to lead that if no one else wants to - but is there someone else who should or wants to own this? In summary, yes please, sounds good. I would reach out to Dan, and the other folks who were active in those meetings, to see how it best makes sense to collaborate. Let me know if I can help connect you folks, but IRC usually works. I'm mostly just lurking on IRC but keep an eye out on this mailing list for anything tagged with [nova]. So if there's any times my input is needed I should catch the mails as long as they're on the list. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
On Fri, May 29, 2015 at 06:32:18PM +0100, Neil Jerram wrote: Hi all, Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is being somewhat driven by the etherpad at [2]. But this etherpad doesn't have a section for libvirt / vif driver changes. The log at [1] briefly touched on this, but moved on after noting that Dan PB had disbanded a libvirt subteam for lack of interest. So, what should folk interested in libvirt / vif work (including me) now do? I think the answer is that we should self-organize, then report to the next IRC on how we've done that, and I'm happy to lead that if no one else wants to - but is there someone else who should or wants to own this? I'm of a mindset that aims to avoid creating rules bureaucracy, so don't feel you need to get permission to form a special interest group to work on the libvirt VIF drivers. Any group of interested devs should just collaborate and divide work up between themselves. I just strongly suggest that you work to keep any design / technical discussions in public forums. ie have your email discussions on this openstack-dev mailing list or #nova IRC, and not in private CC'd email threads between the special interest team. This ensures that anyone with interest can watch what's going on, without having to formally join any team. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
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
Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers
Hi Neil, First of all thank for organizing this. Both Infiniband SR-IOV VIF type and Removal of mlnx_direct VIF type are ready for core review. -Original Message- From: Neil Jerram [mailto:neil.jer...@metaswitch.com] Sent: Monday, June 01, 2015 8:38 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers 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-dev] [nova] Progressing/tracking work on libvirt / vif drivers
Hi all, Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is being somewhat driven by the etherpad at [2]. But this etherpad doesn't have a section for libvirt / vif driver changes. The log at [1] briefly touched on this, but moved on after noting that Dan PB had disbanded a libvirt subteam for lack of interest. So, what should folk interested in libvirt / vif work (including me) now do? I think the answer is that we should self-organize, then report to the next IRC on how we've done that, and I'm happy to lead that if no one else wants to - but is there someone else who should or wants to own this? Thanks, Neil [1] http://eavesdrop.openstack.org/meetings/nova/2015/nova.2015-05-28-14.02.log.html [2] https://etherpad.openstack.org/p/liberty-nova-priorities-tracking __ 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
