On 05/04/2016 09:42 AM, Luis Gomez wrote: > > >> 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 :)
not that I knew before 15m ago, but check page 157 for an example: https://drive.google.com/file/d/0B_rLr6so6DZ8RVJyWXpVcEdhdVE/view?usp=sharing JamO >> >> 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
