Open Stack

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 [1]
> in Juno?
> 
> VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user
> [2] 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 [3].
>
> 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 :|