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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
