Speaking on behalf of Tap-as-a-Service members, we would also be very much interested in the following initiative.... :)
On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > Cathy Zhang <cathy.h.zh...@huawei.com> wrote: > > >> I think there is no formal spec or anything, just some emails around >> there. >> >> That said, I don’t follow why it’s a requirement for SFC to switch to l2 >> agent extension mechanism. Even today, with SFC maintaining its own agent, >> there are no clear guarantees for flow priorities that would avoid all >> possible conflicts. >> >> Cathy> There is no requirement for SFC to switch. My understanding is >> that current L2 agent extension does not solve the conflicting entry issue >> if two features inject the same priority table entry. I think this new L2 >> agent effort is try to come up with a mechanism to resolve this issue. Of >> course if each feature( SFC or Qos) uses its own agent, then there is no >> coordination and no way to avoid conflicts. >> > > Sorry, I probably used misleading wording. I meant, why do we consider the > semantic flow management support in l2 agent extension framework a > *prerequisite* for SFC to switch to l2 agent extensions? The existing > framework should already allow SFC to achieve what you have in the > subproject tree implemented as a separate agent (essentially a fork of OVS > agent). It will also set SFC to use standard extension mechanisms instead > of hacky inheritance from OVS agent classes. So even without the strict > semantic flow management, there is benefit for the subproject. > > With that in mind, I would split this job into 3 pieces: > * first, adopt l2 agent extension mechanism for SFC functionality > (dropping custom agent); > * then, work on semantic flow management support in OVS agent API class > [1]; > * once the feature emerges, switch SFC l2 agent extension to the new > framework to manage SFC flows. > > I would at least prioritize the first point and target it to Newton-1. > Other bullet points may take significant time to bake. > > [1] > https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py > > > Ihar > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks and Regards, Reedip Banerjee IRC: reedip
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
