<div dir="ltr"><div><div>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.<br>
</div><br>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.<br>
<br>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.<br>-- <br></div>Ian.<br><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 27 August 2014 07:30, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Wed, Aug 27, 2014 at 04:06:25PM +0200, Luke Gorrie wrote:<br>
> Howdy!<br>
><br>
> I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1]<br>
> in Juno?<br>
><br>
> VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user<br>
> [2] that allows a guest to do Virtio-net I/O via a userspace vswitch. This<br>
> makes it convenient to deploy new vswitches that are optimized for NFV<br>
> workloads, of which there are now several both open source and proprietary.<br>
><br>
> The complication is that we have no CI coverage for this feature in Juno.<br>
> Originally we had anticipated merging a Neutron driver that would exercise<br>
> vhost-user but the Neutron core team requested that we develop that outside<br>
> of the Neutron tree for the time being instead [3].<br>
><br>
> We are hoping that the Nova team will be willing to merge the feature even<br>
> so. Within the NFV subgroup it would help us to share more code with each<br>
> other and also be good for our morale :) particularly as the QEMU work was<br>
> done especially for use with OpenStack.<br>
<br>
</div>Our general rule for accepting new VIF drivers in Nova is that Neutron<br>
should have accepted the corresponding other half of VIF driver, since<br>
nova does not want to add support for things that are not in-tree for<br>
Neutron.<br>
<br>
In this case addign the new VIF driver involves defining a new VIF type<br>
and corresponding metadata associated with it. This metadata is part of<br>
the public API definition, to be passed from Neutron to Nova during VIF<br>
plugging and so IMHO this has to be agreed upon and defined in tree for<br>
Neutron & Nova. So even if the VIF driver in Neutron were to live out<br>
of tree, at a very minimum I'd expect the VIF_VHOSTUSER part to be<br>
specified in-tree to Neutron, so that Nova has a defined interface it<br>
can rely on.<br>
<br>
So based on this policy, my recommendation would be to keep the Nova VIF<br>
support out of tree in your own branch of Nova codebase until Neutron team<br>
are willing to accept their half of the driver.<br>
<br>
In cases like this I think Nova & Neutron need to work together to agree<br>
on acceptance/rejection of the proposed feature. Having one project accept<br>
it and the other project reject, without them talking to each other is not<br>
a good position to be in.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>