Open Stack

Kyle Mestery <mestery at 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