[openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?

Manish Godara manishg at yahoo-inc.com
Tue Nov 4 09:12:19 UTC 2014


Clearing all flows upon agent restart is a major issue, imho.  We should really look at this with higher priority than the modular L2 agent as the timeline of the refactor isn't clear for the modular layer 2 agent.  Whatever the issue was, I think we ought to be able to find a better solution that doesn't disrupt the network.  I agree that reconciling data after a restart is not straight-forward in all scenarios but there should be an option to just do basic sanity and not interrupt existing flows.  I'd like to help out on this (if needed) - there is a blueprint [1] that was suggested but I'm not sure who the owner is and what the status is.  If anyone is working on this and is at the summit this week, please let me know.  We can meet one of the days here at the summit.





thanks,

manish





[1] Adding an option of "Soft Restart" in neutron agent along with o... : Blueprints : neutron


|   |
|   |  |   |   |   |   |   |
| Adding an option of "Soft Restart" in neutron agent alon...While the blueprint of "ovs-firewall-driver" is being developed, a new concern comes up. When an ovs agent (or an ml2 agent with ovs) restarts, if it cleans up all ... |
|  |
| View on blueprints.launchpad.net | Preview by Yahoo |
|  |
|   |


  
     On Friday, October 31, 2014 7:32 AM, Ben Nemec <openstack at nemebean.com> wrote:
   

 On 10/29/2014 10:17 AM, Kyle Mestery wrote:
> On Wed, Oct 29, 2014 at 7:25 AM, Hly <henry4hly at gmail.com> wrote:
>>
>>
>> Sent from my iPad
>>
>> On 2014-10-29, at 下午8:01, Robert van Leeuwen <Robert.vanLeeuwen at spilgames.com> wrote:
>>
>>>>> I find our current design is remove all flows then add flow by entry, this
>>>>> will cause every network node will break off all tunnels between other
>>>>> network node and all compute node.
>>>> Perhaps a way around this would be to add a flag on agent startup
>>>> which would have it skip reprogramming flows. This could be used for
>>>> the upgrade case.
>>>
>>> I hit the same issue last week and filed a bug here:
>>> https://bugs.launchpad.net/neutron/+bug/1383674
>>>
>>> From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent.
>>> e.g. something simple like changing a log setting becomes a hassle.
>>> I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it.
>>>
>>
>> +1, we also suffered from this even when a very little patch is done
>>
> I'd really like to get some input from the tripleo folks, because they
> were the ones who filed the original bug here and were hit by the
> agent NOT reprogramming flows on agent restart. It does seem fairly
> obvious that adding an option around this would be a good way forward,
> however.

Since nobody else has commented, I'll put in my two cents (though I
might be overcharging you ;-).  I've also added the TripleO tag to the
subject, although with Summit coming up I don't know if that will help.

Anyway, if the bug you're referring to is the one I think, then our
issue was just with the flows not existing.  I don't think we care
whether they get reprogrammed on agent restart or not as long as they
somehow come into existence at some point.

It's possible I'm wrong about that, and probably the best person to talk
to would be Robert Collins since I think he's the one who actually
tracked down the problem in the first place.

-Ben


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141104/5a7f3381/attachment-0001.html>


More information about the OpenStack-dev mailing list