Open Stack

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.

Maybe we can find an other way to support it?
Or, are we going to accept new VIF_TYPE in nova if it's only used by
an external ml2/l2 plugin?

Maxime