Open Stack

On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange <berrange at redhat.com>
wrote:

>
> Yes, I really think this is a key point. When we introduced the VIF type
> mechanism we never intended for there to be soo many different VIF types
> created. There is a very small, finite number of possible ways to configure
> the libvirt guest XML and it was intended that the VIF types pretty much
> mirror that. This would have given us about 8 distinct VIF type maximum.
>
> I think the reason for the larger than expected number of VIF types, is
> that the drivers are being written to require some arbitrary tools to
> be invoked in the plug & unplug methods. It would really be better if
> those could be accomplished in the Neutron code than the Nova code, via
> a host agent run & provided by the Neutron mechanism.  This would let
> us have a very small number of VIF types and so avoid the entire problem
> that this thread is bringing up.
>
> Failing that though, I could see a way to accomplish a similar thing
> without a Neutron launched agent. If one of the VIF type binding
> parameters were the name of a script, we could run that script on
> plug & unplug. So we'd have a finite number of VIF types, and each
> new Neutron mechanism would merely have to provide a script to invoke
>
> eg consider the existing midonet & iovisor VIF types as an example.
> Both of them use the libvirt "ethernet" config, but have different
> things running in their plug methods. If we had a mechanism for
> associating a "plug script" with a vif type, we could use a single
> VIF type for both.
>
> eg iovisor port binding info would contain
>
>   vif_type=ethernet
>   vif_plug_script=/usr/bin/neutron-iovisor-vif-plug
>
> while midonet would contain
>
>   vif_type=ethernet
>   vif_plug_script=/usr/bin/neutron-midonet-vif-plug
>
>
> And so you see implementing a new Neutron mechanism in this way would
> not require *any* changes in Nova whatsoever. The work would be entirely
> self-contained within the scope of Neutron. It is simply a packaging
> task to get the vif script installed on the compute hosts, so that Nova
> can execute it.
>
> This is essentially providing a flexible VIF plugin system for Nova,
> without having to have it plug directly into the Nova codebase with
> the API & RPC stability constraints that implies.
>
>
+1

Port binding mechanism could vary among different networking technologies,
which is not nova's concern, so this proposal makes sense.  Note that some
vendors already provide port binding scripts that are currently executed
directly from nova's vif.py ('mm-ctl' of midonet and 'ifc_ctl' for iovisor
are two such examples), and this proposal makes it unnecessary to have
these hard-coded in nova.  The only question I have is, how would nova
figure out the arguments for these scripts?  Should nova dictate what they
are?

Ryu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141212/17775e59/attachment.html>