Open Stack

On Mon, Jun 22, 2015 at 7:48 PM, Sean M. Collins <sean at coreitpro.com> wrote:

> On Mon, Jun 22, 2015 at 10:47:39AM EDT, Salvatore Orlando wrote:
> > I would probably start with something for enabling the L2 agent to
> process
> > "features" such as QoS and security groups, working on the OVS agent, and
> > then in a second step abstract a driver interface for communicating with
> > the data plane. But I honestly do not know if this will keep the work too
> > "OVS-centric" and therefore won't play well with the current efforts to
> put
> > linux bridge on par with OVS in Neutron. For those question we should
> seek
> > an answer from our glorious reference control plane lieutenant, and
> perhaps
> > also from Sean Collins, who's coordinating efforts around linux bridge
> > parity.
>
> I think that what Salvatore has suggested is good. If we start creating
> good API contracts, and well defined interfaces in the reference control
> plane agents - this is a good first step. Even if we start off by doing
> this just for the OVS agent, that'll be a good template for what we
> would need to do for any agent-driven L2 implementation - and it could
> easily be re-used by others.
>
> To be honest, if you squint hard enough there really are very few
> differences between the OVS agent and the Linux Bridge agent does -
> the parts that handle control plane communication, processing
> data updates, and so forth should all be very similar.
>
> They only become different at the lower
> levels where it's brctl/ip2 vs. ovs-vsctl/of-ofctl CLI calls - so why
> maintain two separate agent implementations when quite a bit of what
> they do is functionally identical?
>

As Miguel mentioned, the patch [1] adds support for QoS driver in L2
Agents. Since QoS support is planned to be leveraged by OVS and SR-IOV and
maybe later by Linux Bridge, the idea is to make common L2Agent layer to
enable generic support for features (extensions) and QoS as the first
feature to support. This is not the Modular L2 Agent, but definitely the
step into the right direction.
This work should have minimal impact on Server side, and mostly about code
reuse by L2 Agents.

[1] https://review.openstack.org/#/c/189723/

BR,
Irena

> --
> Sean M. Collins
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150623/fbb7212e/attachment.html>