<div dir="ltr">I think there are a few factors which influence the ML2 driver vs "monolithic" plugin debate, and they mostly depend on OVN rather than Neutron.<div>From a Neutron perspective both plugins and drivers (as long at they live in their own tree) will be supported in the foreseeable future. If a ML2 mech driver is not the best option for OVN that would be ok - I don't think the Neutron community advices development of a ML2 driver as the preferred way for integrating with new backends.<br></div><div><br></div><div>The ML2 framework provides a long list of benefits that mechanism driver developer can leverage.</div><div>Among those:</div><div>- The ability of leveraging Type drivers which relieves driver developers from dealing with network segment allocation</div><div>- Post-commit and (for most operations) pre-commit hooks for performing operation on the backend</div><div>- The ability to leverage some of the features offered by Neutron's built-in control-plane such as L2-population</div><div>- A flexible mechanism for enabling driver-specific API extensions</div><div>- Promotes modular development and integration with higher-layer services, such as L3. For instance OVN could provide the L2 support for Neutron's built-in L3 control plane</div><div>- The (potential afaict) ability of interacting with other mechanism driver such as those operating on physical appliances on the data center</div><div>- <add your benefit here></div><div><br></div><div>In my opinion OVN developers should look at ML2 benefits, and check which ones apply to this specific platform. I'd say that if there are 1 or 2 checks in the above list, maybe it would be the case to look at developing a ML2 mechanism driver, and perhaps a L3 service plugin.</div><div>It is worth nothing that ML2, thanks to its type and mechanism driver provides also some control plane capabilities. If those capabilities are however on OVN's roadmap it might be instead worth looking at a "monolithic" plugin, which can also be easily implemented by inheriting from neutron.db.db_base_plugin_v2.NeutronDbPluginV2, and then adding all the python mixins for the extensions the plugin needs to support.<br></div><div><br></div><div>Salvatore<br></div><div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2015 at 18:32, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[branching off a discussion on ovs-dev at this point:<br>
<a href="http://openvswitch.org/pipermail/dev/2015-February/051609.html" target="_blank">http://openvswitch.org/pipermail/dev/2015-February/051609.html</a>]<br>
<br>
On Fri, Feb 20, 2015 at 6:56 PM, Kyle Mestery <<a href="mailto:mestery@mestery.com">mestery@mestery.com</a>> wrote:<br>
> One thing to keep in mind, this ties somewhat into my response to Russell<br>
> earlier on the decision around ML2 vs. core plugin. If we do ML2, there are<br>
> type drivers for VLAN, VXLAN, and GRE tunnels. There is no TypeDriver for<br>
> STT tunnels upstream now. It's just an item we need on the TODO list if we<br>
> go down the STT tunnel path.<br>
<br>
It was suggested to me off-list that this part of the discussion should be on<br>
openstack-dev, so here it is ;-)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div>