[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 14:16:01 UTC 2014

On Fri, Dec 12, 2014 at 03:05:28PM +0100, Maxime Leroy wrote:
> On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange
> <berrange at redhat.com> wrote:
> > 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:
> >>
> [..]
> >> 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.
> >
> Many information are used by the plug/unplug method: vif_id,
> vif_address, ovs_interfaceid, firewall, net_id, tenant_id, vnic_type,
> instance_uuid...
> Not sure we can define a set of standard arguments.

That's really not a problem. There will be some set of common info
needed for all. Then for any particular vif type we know what extra
specific fields are define in the port binding metadata. We'll just
set env variables for each of those.

> Maybe instead to use a script we should load some plug/unplug
> functions from a python module with importlib. So a vif_plug_module
> option instead to have a vif_plug_script ?

No, we explicitly do *not* want any usage of the Nova python modules.
That is all private internal Nova implementation detail that nothing
is permitted to rely on - this is why the VIF plugin feature was
removed in the first place.

> There are several other problems to solve if we are going to use this
> vif_plug_script:
> - How to have the authorization to run this script (i.e. rootwrap)?

Yes, rootwrap.

> - How to test plug/unplug function from these scripts?
>   Now, we have unity tests in nova/tests/unit/virt/libvirt/test_vif.py
> for plug/unplug method.

Integration and/or functional tests run for the VIF impl would
exercise this code still.

> - How this script will be installed?
>    -> should it be including in the L2 agent package? Some L2 switch
> doesn't have a L2 agent.

That's just a normal downstream packaging task which is easily
handled by people doing that work. If there's no L2 agent package
they can trivially just create a new package for the script(s)
that need installing on the comput node. They would have to be
doing exactly this anyway if you had the VIF plugin as a python
module instead.

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