Hi mohammad, What I meant in my email is totaly in line with your proposal. My dataplane driver is your resource driver, whereas my controlplane driver is your agent driver! I totally agree that the real challenge is defining a common abstract class for every resource driver. My proposal was to bind a port to a resource driver, so that we can have several resource driver on the same agent. This seems to be the goal the method * ResourceDriver**.port_bound() *in [3], am I wrong?
Tahnks for the etherpad, I will try to participate through it. Mathieu On Sat, May 31, 2014 at 5:10 AM, Mohammad Banikazemi <[email protected]> wrote: > Hi Mathieu, > > 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. > > 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. > > 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. > > 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? > > Mohammad > > [3] https://etherpad.openstack.org/p/modular-l2-agent-outline > > > [image: 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]Mathieu > Rohon ---05/30/2014 06:25:29 AM---Hi all, Modular agent seems to have to > choose between two type of architecture [1]. > > From: Mathieu Rohon <[email protected]> > To: OpenStack Development Mailing List <[email protected]>, > Mohammad Banikazemi/Watson/IBM@IBMUS, > Date: 05/30/2014 06:25 AM > Subject: [openstack-dev][Neutron][ML2] Modular agent architecture > ------------------------------ > > > > Hi all, > > Modular agent seems to have to choose between two type of architecture [1]. > > As I understood during the last ML2 meeting [2], Extension driver > seems to be the most reasonnable choice. > But I think that those two approaches are complementory : Extension > drivers will deal with RPC callbacks form the plugin, wheras Agent > drivers will deal with controlling the underlying technology to > interpret those callbacks. > > It looks like a controlPlane/Dataplane architecture. Could we have a > control plane manager on which each Extension driver should register > (and register callbacks it is listening at), and a data plane manager, > on which each dataplane controller will register (ofagent, ovs, LB..), > and which implement a common abastract class. > A port will be managed by only one dataplane controller, and when a > control plane driver wants to apply a modification on a port, it will > retrieve the correct dataplane controller for this port in order to > call one of the abstracted method to modify the dataplane. > > > [1] > https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions > [2] > http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-05-28-16.02.log.html > > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
