Open Stack

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