Hi Armando, Static configuration really introduces unnecessary burden to the operator. But I can't understand your "explore a way", although it sounds interesting. Can you explain it in detail? Thank you.
BTW, as Sudhakar wrote, [1] attempted to implement the flow synchronization, but without any progress/updates. So how to remind the register. Or if I want to participate in it even work on it alone, what I need do? register another BP? [1] https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart BR, Germy On Thu, Nov 6, 2014 at 2:59 AM, Armando M. <arma...@gmail.com> wrote: > I would be open to making this toggle switch available, however I feel > that doing it via static configuration can introduce unnecessary burden to > the operator. Perhaps we could explore a way where the agent can figure > which state it's supposed to be in based on its reported status? > > Armando > > On 5 November 2014 12:09, Salvatore Orlando <sorla...@nicira.com> wrote: > >> I have no opposition to that, and I will be happy to assist reviewing the >> code that will enable flow synchronisation (or to say it in an easier way, >> punctual removal of flows unknown to the l2 agent). >> >> In the meanwhile, I hope you won't mind if we go ahead and start making >> flow reset optional - so that we stop causing downtime upon agent restart. >> >> Salvatore >> >> On 5 November 2014 11:57, Erik Moe <erik....@ericsson.com> wrote: >> >>> >>> >>> Hi, >>> >>> >>> >>> I also agree, IMHO we need flow synchronization method so we can avoid >>> network downtime and stray flows. >>> >>> >>> >>> Regards, >>> >>> Erik >>> >>> >>> >>> >>> >>> *From:* Germy Lure [mailto:germy.l...@gmail.com] >>> *Sent:* den 5 november 2014 10:46 >>> *To:* OpenStack Development Mailing List (not for usage questions) >>> *Subject:* Re: [openstack-dev] [neutron][TripleO] Clear all flows when >>> ovs agent start? why and how avoid? >>> >>> >>> >>> Hi Salvatore, >>> >>> A startup flag is really a simpler approach. But in what situation we >>> should set this flag to remove all flows? upgrade? restart manually? >>> internal fault? >>> >>> >>> >>> Indeed, only at the time that there are inconsistent(incorrect, >>> unwanted, stable and so on) flows between agent and the ovs related, we >>> need refresh flows. But the problem is how we know this? I think a startup >>> flag is too rough, unless we can tolerate the inconsistent situation. >>> >>> >>> >>> Of course, I believe that turn off startup reset flows action can >>> resolve most problem. The flows are correct most time after all. But >>> considering NFV 5 9s, I still recommend flow synchronization approach. >>> >>> >>> >>> BR, >>> >>> Germy >>> >>> >>> >>> On Wed, Nov 5, 2014 at 3:36 PM, Salvatore Orlando <sorla...@nicira.com> >>> wrote: >>> >>> From what I gather from this thread and related bug report, the change >>> introduced in the OVS agent is causing a data plane outage upon agent >>> restart, which is not desirable in most cases. >>> >>> >>> >>> The rationale for the change that introduced this bug was, I believe, >>> cleaning up stale flows on the OVS agent, which also makes some sense. >>> >>> >>> >>> Unless I'm missing something, I reckon the best way forward is actually >>> quite straightforward; we might add a startup flag to reset all flows and >>> not reset them by default. >>> >>> While I agree the "flow synchronisation" process proposed in the >>> previous post is valuable too, I hope we might be able to fix this with a >>> simpler approach. >>> >>> >>> >>> Salvatore >>> >>> >>> >>> On 5 November 2014 04:43, Germy Lure <germy.l...@gmail.com> wrote: >>> >>> Hi, >>> >>> >>> >>> Consider the triggering of restart agent, I think it's nothing but: >>> >>> 1). only restart agent >>> >>> 2). reboot the host that agent deployed on >>> >>> >>> >>> When the agent started, the ovs may: >>> >>> a.have all correct flows >>> >>> b.have nothing at all >>> >>> c.have partly correct flows, the others may need to be reprogrammed, >>> deleted or added >>> >>> >>> >>> In any case, I think both user and developer would happy to see that the >>> system recovery ASAP after agent restarting. The best is agent only push >>> those incorrect flows, but keep the correct ones. This can ensure those >>> business with correct flows working during agent starting. >>> >>> >>> >>> So, I suggest two solutions: >>> >>> 1.Agent gets all flows from ovs and compare with its local flows after >>> restarting. And agent only corrects the different ones. >>> >>> 2.Adapt ovs and agent. Agent just push all(not remove) flows every time >>> and ovs prepares two tables for flows switch(like RCU lock). >>> >>> >>> >>> 1 is recommended because of the 3rd vendors. >>> >>> >>> >>> BR, >>> >>> Germy >>> >>> >>> >>> >>> >>> On Fri, Oct 31, 2014 at 10:28 PM, Ben Nemec <openst...@nemebean.com> >>> wrote: >>> >>> On 10/29/2014 10:17 AM, Kyle Mestery wrote: >>> > On Wed, Oct 29, 2014 at 7:25 AM, Hly <henry4...@gmail.com> wrote: >>> >> >>> >> >>> >> Sent from my iPad >>> >> >>> >> On 2014-10-29, at 下午8:01, Robert van Leeuwen < >>> robert.vanleeu...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
