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:[email protected]] > 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 :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
