Open Stack

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per
Ihar's suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> Cathy Zhang <Cathy.H.Zhang at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160526/a1c92238/attachment.html>