On Wed, Aug 27, 2014 at 04:06:25PM +0200, Luke Gorrie wrote: > Howdy! > > I am writing to ask whether it will be possible to merge VIF_VHOSTUSER  > in Juno? > > VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user >  that allows a guest to do Virtio-net I/O via a userspace vswitch. This > makes it convenient to deploy new vswitches that are optimized for NFV > workloads, of which there are now several both open source and proprietary. > > The complication is that we have no CI coverage for this feature in Juno. > Originally we had anticipated merging a Neutron driver that would exercise > vhost-user but the Neutron core team requested that we develop that outside > of the Neutron tree for the time being instead . > > We are hoping that the Nova team will be willing to merge the feature even > so. Within the NFV subgroup it would help us to share more code with each > other and also be good for our morale :) particularly as the QEMU work was > done especially for use with OpenStack.
Our general rule for accepting new VIF drivers in Nova is that Neutron should have accepted the corresponding other half of VIF driver, since nova does not want to add support for things that are not in-tree for Neutron. In this case addign the new VIF driver involves defining a new VIF type and corresponding metadata associated with it. This metadata is part of the public API definition, to be passed from Neutron to Nova during VIF plugging and so IMHO this has to be agreed upon and defined in tree for Neutron & Nova. So even if the VIF driver in Neutron were to live out of tree, at a very minimum I'd expect the VIF_VHOSTUSER part to be specified in-tree to Neutron, so that Nova has a defined interface it can rely on. So based on this policy, my recommendation would be to keep the Nova VIF support out of tree in your own branch of Nova codebase until Neutron team are willing to accept their half of the driver. In cases like this I think Nova & Neutron need to work together to agree on acceptance/rejection of the proposed feature. Having one project accept it and the other project reject, without them talking to each other is not a good position to be in. 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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev