> On May 4, 2016, at 9:40 AM, Jamo Luhrsen <[email protected]> wrote: > > > > On 05/04/2016 09:31 AM, Luis Gomez wrote: >> >>> On May 4, 2016, at 9:22 AM, Jamo Luhrsen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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. >> >> I am good with setting higher standards for SRs. We can write a draft an >> present it in the TSC. > > An, > > do we define what can/cannot make it in to an SRs? > > >>> >>> 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? >> >> My answer here is people can use non-released code at their own risk. > > wait, it's not released code or it's just not the default plugin that is > consumed > by other projects. > > I can easily take Beryllium (or Lithium for that matter) and install the -li > plugin > if that's all I need for my purposes. We even explain how to use it in the > user > guide.
I thought there was no mention of Li plugin in the the release documentation, if there is then it is blocker :) > > JamO > > >>> >>> 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]> <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]> >>>>>> <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]> >>>>>> <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]> >>>>>> <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]> >>>>>> <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 <http://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 <http://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 >>>>>>>> <http://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 >>>>>>> <http://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 <http://gmail.com/>> <http://gmail.com >>>>>>>> <http://gmail.com/>>>; >>>>>>>> openflowplugin-dev < >>>>>>> openflowplugin-dev at lists.opendaylight.org >>>>>>> <http://lists.opendaylight.org/> <http://lists.opendaylight.org >>>>>>> <http://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/> <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 >>>>>>>> <http://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 >>>>>>> <http://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]> >>>>>> <mailto:[email protected]> >>>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev____ >>>>>> >>>>>> >>>>>> >>>>>> ____ >>>>>> >>>>>> __ __ >>>>>> >>>>>> -- ____ >>>>>> >>>>>> Thanks____ >>>>>> >>>>>> Anil____ >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> openflowplugin-dev mailing list >>>>> [email protected] >>>>> <mailto:[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
