"Daniel P. Berrange" <berra...@redhat.com> writes:
> 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.
I agree that this is a very promising idea. But... what about the
problem that it is libvirt-specific? Does that matter?
Regards,
Neil
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
