Open Stack

On Thu, Dec 11, 2014 at 2:37 AM, henry hly <henry4hly at gmail.com> wrote:
> On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
[..]
>>
>> The problem is that we effectively prevent running an out of tree Neutron
>> driver (which *is* perfectly legitimate) if it uses a VIF plugging mechanism
>> that isn't in Nova, as we can't use out of tree code and we won't accept in
>> code ones for out of tree drivers.
>

+1 well said !

> The question is, do we really need such flexibility for so many nova vif types?
>

Are we going to accept a new VIF_TYPE in nova if it's only used by an
external ml2/l2 plugin ?

> 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.

VIF_TYPE_TAP and VIF_TYPE_VHOSTUSER is nice if your out-of-tree l2/ml2
plugin needs a tap interface or a vhostuser socket.

But 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 not supported in the nova tree, you still need to
have a plugin mechanism.

[..]
>> Your issue is one of testing.  Is there any way we could set up a better
>> testing framework for VIF drivers where Nova interacts with something to
>> test the plugging mechanism actually passes traffic?  I don't believe
>> there's any specific limitation on it being *Neutron* that uses the plugging
>> interaction.

My spec proposes to use the same plugin mechanism for the vif drivers
in the tree and for the external vif drivers. Please see my RFC patch:
https://review.openstack.org/#/c/136857/

Maxime