[openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver
Daniel P. Berrange
berrange at redhat.com
Fri Dec 12 09:46:39 UTC 2014
On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote:
> On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange <berrange at redhat.com>
> > 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.
> 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
We could define some standard set of arguments & environment variables
to pass the information from the VIF to the script in a standard way.
|: 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 :|
More information about the OpenStack-dev