On Thu, Dec 11, 2014 at 2:37 AM, henry hly <[email protected]> wrote: > On Thu, Dec 11, 2014 at 3:48 AM, Ian Wells <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
