Thanks for the blocking bug definitions, Luis. They seem reasonable to me.
What about SRs though? Should they be treated differently? I was under the impression that, in general, only bug fixes would go in to SRs. If that's the case then we can hold SRs to a slightly higher standard. BTW, for this specific issue and the -li plugin wouldn't we expect forward thinking consumers to be using it, assuming they realize this is the plugin that will be default going forward. I do remember talking with someone at our last Summit (9-10mo ago) and they implied that real customers were using the -li plugin version because it was more stable. Are we breaking them with Be SR2? JamO On 05/03/2016 11:58 PM, Luis Gomez wrote: > Hi Jamo, I agree with you, we should avoid any kind of regression when we > release something. > > Regarding what is blocker we have this definition for reference in the > Weather wiki: > > > Blocking Bugs definition > > Blocking bugs may meet one or more of the following conditions: > > * Cause a major controller-wide regression. e.g: A bug in openflowplugin > prevents OpenFlow switches from connecting. > * Cause a major regression in another project. e.g: A bug in OVSDB causes > GBP service to fail. > * Dramatically decrease controller performance or scale. e.g: A bug in > yangtools causes OpenFlow perf test results to decrease by an order of > magnitude. > * Are immediately obvious to users. e.g: A bug in DLUX makes topology > unavailable in the GUI. > > Generally, major regressions are likely candidates. Of course, terms like > "major" require substantial case-by-case interpretation. > > > This particular issue: "OF plugin Li feature fails to deploy in cluster" > would be a "major" controller regression if it was not because afaik and > after lot of discussion we never released the Li plugin in Beryllium, not > even as individual feature. So to me this is a "major regression" in a non > released functionality which makes the bug non blocking imo. > > BR/Luis > > >> On May 3, 2016, at 10:30 PM, Jamo Luhrsen <[email protected] >> <mailto:[email protected]>> wrote: >> >> I know I'm the oddball here, but I am against releasing an SR with a known >> regression. Even >> if the regression is in a non-default feature, or intermittent or some other >> rare corner of >> our product. If it's truly a regression, then something has changed that we >> should track >> down and resolve. >> >> Hopefully that can be part of our culture and process. If regressions are >> sneaking in, then >> I say we have to pay the price to fix them and try to get better at >> preventing them. >> >> We have nowhere near 100% system test coverage (if that's even possible), so >> one worry is >> that whatever this regression is lurking in other places. >> >> it's only my 2c. >> >> JamO >> >> >> >> >> On 05/03/2016 06:18 PM, Abhijit Kumbhare wrote: >>> Yes - that is what we were discussing on the OpenFlow Plugin IRC. This is >>> not a blocker since it does not affect the end users - however we can wait >>> till Wednesday morning (say 10 am Pacific) to get a response/fix from Jozef >>> (with Michal's help in merging it). Apparently it takes 24 hours for a >>> respin - 12 hours to build & 12 hours to get approvals from project leads. >>> If the ETA for the fix in the morning from Jozef pushes the build beyond >>> the TSC meeting - then we should skip. >>> >>> On Tue, May 3, 2016 at 5:55 PM, An Ho <[email protected] >>> <mailto:[email protected]> <mailto:[email protected]>> wrote: >>> >>> I agree with this Anil. Beryllium end users should not be using the Li >>> Plugin Design.____ >>> >>> __ __ >>> >>> If Jamo, Abhijit, and Jozef agrees with this, then we should mark the >>> issue as not a regression blocker and OKAY to release.____ >>> >>> __ __ >>> >>> Best Regards,____ >>> >>> An Ho____ >>> >>> __ __ >>> >>> *From:*Anil Vishnoi [mailto:[email protected] >>> <mailto:[email protected]>] >>> *Sent:* Tuesday, May 03, 2016 5:48 PM >>> *To:* Abhijit Kumbhare >>> *Cc:* An Ho; [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected]> >>> >>> >>> *Subject:* Re: [openflowplugin-dev] Li plugin cluster broken____ >>> >>> __ __ >>> >>> In my opinion this is not a blocker, given that this plugin is not a >>> default plugin for Beryllium release.____ >>> >>> __ __ >>> >>> On Tue, May 3, 2016 at 2:45 PM, Abhijit Kumbhare <[email protected] >>> <mailto:[email protected]> <mailto:[email protected]>> wrote:____ >>> >>> I would like to know Jozef's thoughts on this.____ >>> >>> __ __ >>> >>> On Tue, May 3, 2016 at 1:15 PM, An Ho <[email protected] >>> <mailto:[email protected]> <mailto:[email protected]>> wrote:____ >>> >>> Have we been able to determine if this is a blocker, in the sense that >>> some end-user functionality that worked in SR1 no longer works in SR2? >>> Also, do have a known workaround for the issue? Could we release SR2 >>> with this known bug and workaround and target a fix in SR3? >>> >>> Another concern I have is that Beryllium SR2 Build 20160425 did not find >>> any regression issues in openflowplugin and we have not merged nay >>> patches that impacted openflowplugin in the Beryllium branches. >>> >>> Best Regards, >>> An Ho >>> >>> From: Abhijit Kumbhare abhijitkoss at gmail.com <http://gmail.com> >>> <http://gmail.com> >>> Subject: Tue May 3 15:49:42 UTC 2016 >>> >>> >>> Can you share the list of the patches Jozef? >>> >>> Thanks, >>> Abhijit >>> >>> On Tue, May 3, 2016 at 8:47 AM, Jamo Luhrsen <jluhrsen at gmail.com >>> <http://gmail.com> <http://gmail.com>> wrote: >>> >>>> just to confirm that this should not be a blocker for SR2, right? >>>> >>>> if so, we'll need your patches merged (and associated with a bug) and a >>>> respin of >>>> SR2. >>>> >>>> Thanks, >>>> JamO >>>> >>>> On 05/03/2016 01:56 AM, Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES >>>> at Cisco) wrote: >>>>> This is happening, occasionally, we solved it already in plugin. Patches >>>> are ready to be merged we just wait for beryllium to be unlocked. >>>>> >>>>> Jozef >>>>> >>>>> -----Original Message----- >>>>> From: openflowplugin-dev-bounces at lists.opendaylight.org >>>>> <http://lists.opendaylight.org> <http://lists.opendaylight.org> [mailto: >>>> openflowplugin-dev-bounces at lists.opendaylight.org >>>> <http://lists.opendaylight.org> <http://lists.opendaylight.org>] On Behalf >>>> Of Jamo >>>> Luhrsen >>>>> Sent: 3. mája 2016 5:57 >>>>> To: Luis Gomez <ecelgp at gmail.com <http://gmail.com> >>>>> <http://gmail.com>>; openflowplugin-dev < >>>> openflowplugin-dev at lists.opendaylight.org >>>> <http://lists.opendaylight.org> <http://lists.opendaylight.org>> >>>>> Subject: Re: [openflowplugin-dev] Li plugin cluster broken >>>>> >>>>> This looks like something that used to happen from time to time. Oldest >>>> example was back on 4/17. However, it currently looks like it's happening >>>> almost every time. That's a bit worrisome. >>>>> >>>>> I tried to recreate locally, but could not. >>>>> >>>>> not sure if that's helpful or not, but wanted to share. >>>>> >>>>> JamO >>>>> >>>>> On 05/02/2016 10:19 AM, Luis Gomez wrote: >>>>>> Hi, >>>>>> >>>>>> It seems Li plugin cluster is broken for few days now. The ERROR is >>>>>> 401 Unauthorized answer when polling the NB REST API. This happens when >>>> controller does not start properly. >>>>>> >>>>>> https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowpl >>>>>> ugin-csit-3node-clustering-only-boron >>>>>> >>>>>> _https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowp >>>>>> lugin-csit-3node-clustering-only-beryllium/_ >>>>>> >>>>>> BR/Luis >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ openflowplugin-dev >>>>>> mailing list openflowplugin-dev at lists.opendaylight.org >>>>>> <http://lists.opendaylight.org> >>>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>>>> >>>>> _______________________________________________ >>>>> openflowplugin-dev mailing list >>>>> openflowplugin-dev at lists.opendaylight.org >>>>> <http://lists.opendaylight.org> <http://lists.opendaylight.org> >>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>>> >>>> _______________________________________________ >>>> openflowplugin-dev mailing list >>>> openflowplugin-dev at lists.opendaylight.org >>>> <http://lists.opendaylight.org> <http://lists.opendaylight.org> >>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>> ____ >>> >>> __ __ >>> >>> >>> _______________________________________________ >>> openflowplugin-dev mailing list >>> [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected]> >>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev____ >>> >>> >>> >>> ____ >>> >>> __ __ >>> >>> -- ____ >>> >>> Thanks____ >>> >>> Anil____ >>> >>> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
