Open Stack

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 <mb at us.ibm.com> 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 <mathieu.rohon at gmail.com>
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
> Mohammad Banikazemi/Watson/IBM at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140603/c4bd856e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140603/c4bd856e/attachment.gif>