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:berra...@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.

|: 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-dev mailing list

Reply via email to