<div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Could we remove all device related adaption(rest/ssh/netconf/of..</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">. proxy) from these mechanism driver to the agent side, leaving only necessary code in the plugin?</span><div>

<span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">I'm not sure I understand what you are advocating removing vs leaving in the plugin. I know that some of the drivers are used to configure the physical fabric to push vlans down to the port that the hypervisor is plugged into and are meant to be used in conjunction with the openvswitch driver. </span></div>

<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">While it might make sense for the port-level operations to be done at an agent level, it doesn't work very well if they require a lot of queries to driver specific DBs. It</span><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"> makes less sense when it comes to network and subnet-level operations because there isn't really a mapping between a network and specific agent, so it would just have to be fulfilled by a random agent which again may require several DB calls back to the central neutron DB.</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Could you elaborate a little more on what types of code should be stripped out of drivers and moved to agents?</span></div>

<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">--</span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Kevin Benton</span></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 1:17 AM, henry hly <span dir="ltr"><<a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>ML2 mechanism drivers are becoming another kind of "plugins". Although they can be loaded together, but can not work with each other.<br></div><div><br></div><div>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.</div>


<div><br></div><div>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?</div>


<div><br></div><div>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? </div>


<div><br></div><div>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.</div>


</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>