Open Stack

On Wed, Dec 10, 2014 at 07:41:55AM +0000, Irena Berezovsky wrote:
> Hi Daniel,
> Please see inline
> 
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com] 
> Sent: Tuesday, December 09, 2014 4:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver
> 
> The VIF parameters are mapped into the nova.network.model.VIF class which is doing some crude validation. I would anticipate that this validation will be increasing over time, because any functional data flowing over the API and so needs to be carefully managed for upgrade reasons.
> 
> Even if the Neutron impl is out of tree, I would still expect both Nova and Neutron core to sign off on any new VIF type name and its associated details (if any).
> 
> [IB] This maybe the reasonable integration point. But it requires nova team review and approval. From my experience nova team is extremely overloaded, therefor getting this code reviewed become very difficult mission.
>  
> > What other reasons am I missing to not have VIF driver classes as a 
> > public extension point ?
> 
> Having to find & install VIF driver classes from countless different vendors, each hiding their code away in their own obsecure website, will lead to awful end user experiance when deploying Nova. Users are better served by having it all provided when they deploy Nova IMHO
> 
> If every vendor goes off & works in their own isolated world we also loose the scope to align the implementations, so that common concepts work the same way in all cases and allow us to minimize the number of new VIF types required. The proposed vhostuser VIF type is a good example of this - it allows a single Nova VIF driver to be capable of potentially supporting multiple different impls on the Neutron side.
> If every vendor worked in their own world, we would have ended up with multiple VIF drivers doing the same thing in Nova, each with their own set of bugs & quirks.
> 
> [IB] I think that most of the vendors that maintain vif_driver out of nova, do not do it on purpose and would prefer to see it upstream. Sometimes host side binding is not fully integrated with libvirt and requires some temporary additional code, till libvirt provides complete support. Sometimes, it is just lack of nova team attention to the proposed spec/code  to be reviewed and accepted on time, which ends up with fully supported neutron part and missing small but critical vif_driver piece.


So the problem of Nova review bandwidth is a constant problem across all
areas of the code. We need to solve this problem for the team as a whole
in a much broader fashion than just for people writing VIF drivers. The
VIF drivers are really small pieces of code that should be straightforward
to review & get merged in any release cycle in which they are proposed.
I think we need to make sure that we focus our energy on doing this and
not ignoring the problem by breaking stuff off out of tree.

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