Open Stack

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?

-- 
Sean M. Collins