+100! So, for the vif-type-vhostuser, a general script path name replace the vif-detail "vhost_user_ovs_plug", because it's not the responsibility of nova to understand it.
On Thu, Dec 11, 2014 at 11:24 PM, Daniel P. Berrange <berra...@redhat.com> wrote: > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
