<html><body>
<p><font size="2" face="sans-serif">Hi Mathieu,</font><br>
<br>
<font size="2" face="sans-serif">Thanks for the email. As discussed during the ML2 IRC meeting [2], we have not decided on a design. That is why we do not have a spec for review yet. The idea is that we spend a bit more time and figure out the details and try out some possible options before we go ahead with the spec. So new comments/suggestions are much appreciated.</font><br>
<br>
<font size="2" face="sans-serif">In addition to having different drivers we want to reduce the code replication across current agents. I am wondering if with what you are proposing as dataplane drivers, we will end up with having different drivers which look like the current agents and we do not deal with reducing code replication across agents. If this is not a correct assessment could you describe how we can avoid code replication across agents/drivers.</font><br>
<br>
<font size="2" face="sans-serif">Let me briefly explain what I have outlined in [3] (also mentioned in [2]). We are thinking of having drivers for each extension or probably better said each functionality. So we can have a base l2 connectivity driver, an l2pop driver, a sg driver (not to be confused with sq drivers), so on so forth. I think in your email you are referring to these drivers (or something close to them) as Extension drivers. In [3] they are called Agent Drivers.</font><br>
<br>
<font size="2" face="sans-serif">Then we have the Resource Drivers which will be essentially used for realizing these features depending on the technology/resource being used (e.g., using OVS switches, or Linux Bridges, or some other technology). The main reason for using such a organization is to be able to have different agent drivers utilize the same resource and reuse code. The challenge is figuring out the api for such a driver. Any thoughts on this?</font><br>
<br>
<font size="2" face="sans-serif">Mohammad</font><br>
<br>
<font size="2" face="sans-serif">[3] </font><font size="2" face="sans-serif"><a href="https://etherpad.openstack.org/p/modular-l2-agent-outline">https://etherpad.openstack.org/p/modular-l2-agent-outline</a></font><br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF67BDFF856DC8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Mathieu Rohon ---05/30/2014 06:25:29 AM---Hi all, Modular agent seems to have to choose between two t"><font size="2" color="#424282" face="sans-serif">Mathieu Rohon ---05/30/2014 06:25:29 AM---Hi all, Modular agent seems to have to choose between two type of architecture [1].</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Mathieu Rohon <mathieu.rohon@gmail.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, Mohammad Banikazemi/Watson/IBM@IBMUS, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">05/30/2014 06:25 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[openstack-dev][Neutron][ML2] Modular agent architecture</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hi all,<br>
<br>
Modular agent seems to have to choose between two type of architecture [1].<br>
<br>
As I understood during the last ML2 meeting [2], Extension driver<br>
seems to be the most reasonnable choice.<br>
But I think that those two approaches are complementory : Extension<br>
drivers will deal with RPC callbacks form the plugin, wheras Agent<br>
drivers will deal with controlling the underlying technology to<br>
interpret those callbacks.<br>
<br>
It looks like a controlPlane/Dataplane architecture. Could we have a<br>
control plane manager on which each Extension driver should register<br>
(and register callbacks it is listening at), and a data plane manager,<br>
on which each dataplane controller will register (ofagent, ovs, LB..),<br>
and which implement a common abastract class.<br>
A port will be managed by only one dataplane controller, and when a<br>
control plane driver wants to apply a modification on a port, it will<br>
retrieve the correct dataplane controller for this port in order to<br>
call one of the abstracted method to modify the dataplane.<br>
<br>
<br>
[1]</font></tt><tt><font size="2"><a href="https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions">https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions</a></font></tt><tt><font size="2"><br>
[2]</font></tt><tt><font size="2"><a href="http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-05-28-16.02.log.html">http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-05-28-16.02.log.html</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>