Open Stack

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>
> 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?

We could define some standard set of arguments & environment variables
to pass the information from the VIF to the script in a standard way.

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 :|