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

On 27 August 2014 07:30, Daniel P. Berrange <> 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
> --
> |:      -o-
> :|
> |:              -o-   
> :|
> |:       -o-
> :|
> |:       -o-
> :|
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to