Daniel, if I got it right, the vif script blueprint only is about plug/unplug operations and not about generating new xml representations for vif types. What if for a new vif type it's sufficient to have the get_config_* method updated? In this case plug/unplug would be handled by libvirt (like with many other existing vif types). The plug/unplug methods would just contain a "pass".
Would you tend to be supportive in such cases? Thanks! -- Andreas (irc: scheuran) On Tue, 2015-06-09 at 15:28 +0100, Daniel P. Berrange wrote: > On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote: > > On 04/06/15 13:05, Neil Jerram wrote: > > >Hi John, > > > > > >On 04/06/15 12:21, John Garbutt wrote: > > >>Hi, > > >> > > >>We had a great discussion at the summit around priorities: > > >>https://etherpad.openstack.org/p/YVR-nova-liberty-priorities > > >> > > >>I have made a stab at writing that up here, please to review if you > > >>are interested: > > >>https://review.openstack.org/#/c/187272/ > > >> > > >>Note we plan to keep focus on the reviews using the etherpad like we > > >>did in kilo: > > >>https://etherpad.openstack.org/p/liberty-nova-priorities-tracking > > > > > >As you may have seen, I've collated libvirt/VIF type work at > > >https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. Where > > >would you prefer any discussion about that to continue? Here on the ML, > > >or in that review job? > > > > Hello again... > > > > So, just pinging again about the libvirt/VIF type work that I've collated at > > https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. I'm keen if > > possible to have some kind of next step for discussing whether and how this > > work can be integrated into Nova's Liberty cycle. > > > > I wonder if it would help to present this work at a higher level - > > especially as it's really a grouping of three different kinds of work, and > > it may be that there is an elephant in the room of one of those kinds, which > > needs to be brought more into the open. > > > > Firstly there is a group of simple changes for new VIF types: TAP, macvtap, > > Infiniband SR-IOV; and removal of mlnx_direct. Changes of similar intent, > > scale and scope went in during Kilo, and I imagine that these could be > > reviewed and merged quite quickly, at any time from now on. It would be > > nice from my point of view to have that 'done', and perhaps from others' > > point of view too. > > > > Secondly there is the VIF plug script idea, and it's here that the elephant > > may be. I'm afraid that some of the interested people (including me) missed > > it, but I heard that the core team discussed this and expressed concern, in > > one of the Vancouver sessions, about 'not wanting Nova to become a > > pass-through API'. Since then, spec work has continued, but the only core > > input has come from Dan PB, who wasn't in that Vancouver session - so I'm > > worried that the Nova core team as a whole might not support this idea, and > > that the ongoing spec refinement might turn out to be rearranging the deck > > chairs on the Titanic. > > As you said, I wasn't there, so I don't know what the objections were, but > I'm personally not supportive of adding any new VIF types until we have > the VIF plugging script work done. This concept is critical to preventing > the further explosion in the number of VIF types we need, and in allowing > vendors to add new neutron mechanisms without always requiring a lock-step > update to Nova. > > So from that POV I think the VIF script thing needs to be the #1 priority > wrt VIF driver work in Nova/libvirt for Liberty. > > Regards, > Daniel __________________________________________________________________________ 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
