Kyle Mestery <mest...@mestery.com> wrote:
>> o) Workaround:
>>
>> After a vm is deployed on a (re)started compute node, restart taas
>> agent before creating a tap-service or tap-flow.
>> That is, create taas flows after cleanup has been done.
>>
>> Note that cleanup will be done only once during an ovs-agent is
>> running.
>>
>>
>> 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.
>
>
> API proposal with some consideration for flow cleanup not dropping
flows for
> external code is covered in the following email thread:
>
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html
>
> I believe you would need to adopt the extensions API once it’s in, moving
> from setup with a separate agent for your feature to l2 agent extension
for
> taas that will run inside OVS agent.
>
This is really the right approach here as well. Anything modifying flow
tables and expecting to work with the OVS L2 agent should in fact reside
in the OVS L2 agent or use this extension API. Ihar, is this currently
planned for Mitaka?
Optimistically, yes. But I currently lack comments on the approach before I
bake a spec for that. I would really like to hear from OVS agent folks
(Rossella, Ann, who else?) on whether the proposal is sane at least on high
level. I know some folks were promising quick replies to the thread.
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
