On Thu, Dec 11, 2014 at 04:15:00PM +0100, Maxime Leroy wrote: > On Thu, Dec 11, 2014 at 11:41 AM, Daniel P. Berrange > <berra...@redhat.com> wrote: > > On Thu, Dec 11, 2014 at 09:37:31AM +0800, henry hly wrote: > >> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > >> > On 10 December 2014 at 01:31, Daniel P. Berrange <berra...@redhat.com> > >> > wrote: > >> >> > >> >> > [..] > >> The question is, do we really need such flexibility for so many nova vif > >> types? > >> > >> I also think that VIF_TYPE_TAP and VIF_TYPE_VHOSTUSER is good example, > >> nova shouldn't known too much details about switch backend, it should > >> only care about the VIF itself, how the VIF is plugged to switch > >> belongs to Neutron half. > >> > >> However I'm not saying to move existing vif driver out, those open > >> backend have been used widely. But from now on the tap and vhostuser > >> mode should be encouraged: one common vif driver to many long-tail > >> backend. > > > > 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 > > > > Having less VIF types, then using scripts to plug/unplug the vif in > nova is a good idea. So, +1 for the idea. > > If you want, I can propose a new spec for this. Do you think we have > enough time to approve this new spec before the 18th December? > > Anyway I think we still need to have a vif_driver plugin mechanism: > For example, if your external l2/ml2 plugin needs a specific type of > nic (i.e. a new method get_config to provide specific parameters to > libvirt for the nic) that is not supported in the nova tree.
As I said above, there's a really small finite set of libvirt configs we need to care about. We don't need to have a plugin system for that. It is no real burden to support them in tree 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 OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev