Open Stack

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
-- 
|: 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 :|