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 <jluhr...@gmail.com> 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 <an...@huawei.com >> <mailto:an...@huawei.com>> 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:vishnoia...@gmail.com >> <mailto:vishnoia...@gmail.com>] >> *Sent:* Tuesday, May 03, 2016 5:48 PM >> *To:* Abhijit Kumbhare >> *Cc:* An Ho; openflowplugin-dev@lists.opendaylight.org >> <mailto:openflowplugin-dev@lists.opendaylight.org> >> >> >> *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 <abhijitk...@gmail.com >> <mailto:abhijitk...@gmail.com>> wrote:____ >> >> I would like to know Jozef's thoughts on this.____ >> >> __ __ >> >> On Tue, May 3, 2016 at 1:15 PM, An Ho <an...@huawei.com >> <mailto:an...@huawei.com>> 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> >> 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>> 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> [mailto: >>> openflowplugin-dev-bounces at 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>>; >>>> openflowplugin-dev < >>> openflowplugin-dev at 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> >>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>> >>> _______________________________________________ >>> 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@lists.opendaylight.org >> <mailto:openflowplugin-dev@lists.opendaylight.org> >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev____ >> >> >> >> ____ >> >> __ __ >> >> -- ____ >> >> Thanks____ >> >> Anil____ >> >> > _______________________________________________ > openflowplugin-dev mailing list > openflowplugin-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
