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.

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
  • Re: [openflow... Anil Vishnoi
    • Re: [ope... An Ho
      • Re: ... Abhijit Kumbhare
        • ... Jamo Luhrsen
          • ... Luis Gomez
          • ... Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
          • ... Abhijit Kumbhare
          • ... Jozef Bacigal -X (jbacigal - PANTHEON TECHNOLOGIES at Cisco)
          • ... Jamo Luhrsen
          • ... Luis Gomez
          • ... Jamo Luhrsen
          • ... Luis Gomez
          • ... Jamo Luhrsen

Reply via email to