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.soi...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
