Open Stack

+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
<berrange at 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
>> <berrange at 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.ubuntu at cack.org.uk> wrote:
>> >> > On 10 December 2014 at 01:31, Daniel P. Berrange <berrange at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev