The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackage it, or - ew - patch it in place after installation). I understand where you're coming from but unfortunately the two changes together make things very awkward. Granted that vif_driver needed to go away - it was the wrong level of code and the actual value was coming from the wrong place anyway (nova config and not Neutron) - but it's been removed without a suitable substitute.
It's a little late for a feature for Juno, but I think we need to write something discovers VIF types installed on the system. That way you can add a new VIF type to Nova by deploying a package (and perhaps naming it in config as an available selection to offer to Neutron) *without* changing the Nova tree itself. In the meantime, I recommend you consult with the Neutron cores and see if you can make an exception for the VHOSTUSER driver for the current timescale. -- Ian. On 27 August 2014 07:30, Daniel P. Berrange <berra...@redhat.com> wrote: > 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 > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev