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 <berra...@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 :| _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev