ML2 mechanism drivers are becoming another kind of "plugins". Although they can be loaded together, but can not work with each other.
Today, there are more and more drivers, supporting all kinds of networking hardware and middleware (sdn controller). Unfortunately, they are designed exclusively as chimney REST proxies. A very general use case of heterogeneous networking: we have OVS controlled by ovs agent, and switchs from different vendor, some of them are controller by their own driver/agent directly, others are controlled by a sdn controller middleware. Can we create a vxlan network, across all these sw/hw switchs? It's not so easy: neutron ovs use l2 population mech driver, sdn controllers have their own population way, today most dedicated switch driver can only support vlan. sdn controller people may say: it's ok, just put everything under the control of my controller, leaving ml2 plugin as a shim rest proxy layer. But, shouldn't Openstack Neutron itself be the first class citizen even if there is not controller involved? Could we remove all device related adaption(rest/ssh/netconf/of... proxy) from these mechanism driver to the agent side, leaving only necessary code in the plugin? Heterogeneous networking may become easier, while ofagent give a good example, it can co-exist with native neutron OVS agent in vxlan l2 population. And with the help of coming ML2 agent framework, hardware device or middleware controller adaption agent could be more simplified.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev