[openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver
maxime.leroy at 6wind.com
Thu Dec 11 08:57:40 UTC 2014
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
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:
More information about the OpenStack-dev