Open Stack

If you go this route, taas will have to implement flow recovery logic
itself as well if you want hitless restarts.

On Wed, Dec 16, 2015 at 5:28 PM, Soichi Shigeta <
shigeta.soichi at jp.fujitsu.com> wrote:

>
>  Thank you for your helpful comments.
>
>  I'd like to update my proposal as follows:
>
>   1. Set an integer cookie value to taas flows.
>      Maybe all "1" for short term tentative value.
>   2. Modify the cleanup logic in ovs-agent not to delete flows
>      which have a reserved integer cookie value.
>
>
>
> Sorry, that I don't see this earlier. Yes, cookies have integer values, so
>> we won't be able to set string there. May be we can have a reserved
>> integer
>> cookie value for a project like all "1".
>>
>> I won't support idea of modifying cleanup logic not to drop 0x0 cookies.
>> During implementation of graceful restart it was not dropped at first, but
>> I get rid of it  as having a lot of flows not related to anything was not
>> desirable, so we should try to avoid it here, too.
>>
>> On Wed, Dec 16, 2015 at 7:46 AM, Soichi Shigeta <
>> shigeta.soichi at jp.fujitsu.com> wrote:
>>
>>
>>>     o) An idea to fix:
>>>
>>>>
>>>>        1. Set "taas" stamp(*) to taas flows.
>>>>        2. Modify the cleanup logic in ovs-agent not to delete entries
>>>>           stamped as "taas".
>>>>
>>>>        * Maybe a static string.
>>>>          If we need to use a string which generated dynamically
>>>>          (e.g. uuid), API to interact with ovs-agent is required.
>>>>
>>>>
>>>>    Last week I proposed to set a static string (e.g. "taas") as cookie
>>>    of flows created by taas agent.
>>>
>>>    But I found that the value of a cookie should not be a string,
>>>    but an integer.
>>>
>>>    At line 187 in
>>>
>>> "neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py":
>>>    self.agent_uuid_stamp = uuid.uuid4().int & UINT64_BITMASK
>>>
>>>    In case of we set an integer value to cookie, coordination
>>>    (reservation of range) is required to avoid conflict of cookies with
>>>    other neutron sub-projects.
>>>
>>>    As an alternative (*** short term ***) solution, my idea is:
>>>    Modify the clean up logic in ovs agent not to delete flows whose
>>>    "cookie = 0x0".
>>>    Because old flows created by ovs agent have an old stamp, "cookie =
>>>    0x0" means it was created by other than ovs agent.
>>>
>>>    # But, this idea has a disadvantage:
>>>      If there are flows which have been created by older version of ovs
>>>      agent, they can not be cleaned.
>>>
>>>
>
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151216/e17bc52e/attachment.html>