Open Stack

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 <berrange at 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
> [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
> :|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140830/11835bf5/attachment.html>