Re: [OpenDaylight TSC] [controller-dev] TSC Vote to release latest build # 334 as Sodium SR2

[Abhijit Kumbhare]

Thanks Anil & JamO! I have updated the vote for the Sodium Release 2 to be
for autorelease #339 - and also made it changeable (as Jamo had already
voted on autorelease #334 and may want to change the vote).

On Sun, Feb 9, 2020 at 2:03 PM JamO Luhrsen  wrote:

>
>
> On 2/9/20 8:31 AM, Jamo Luhrsen wrote:
>
> Thanks Anil,
>
> I think the autorelease build you trigger started before the last merge
> job completed from the 5 patches you merged. I kicked off another one
> and probably that's what we can use:
>
>
> https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-sodium-mvn35-openjdk8/340
>
>
> and the integration-test job we will need to vet when in completes in aprox
> 8 hours:
>
>
> https://jenkins.opendaylight.org/releng/job/integration-distribution-test-sodium/479/
>
> Thanks,
> JamO
>
>
>
> Thanks,
> JamO
>
>
> On 2/9/20 4:48 AM, Anil Belur wrote:
>
> Greetings Daniel:
>
> All changes are merged. I've also triggered AR build #339 which should
> pick up these changes.
>
>
> https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-sodium-mvn35-openjdk8/338/
>
> Thanks,
> Anil
>
> On Sat, Feb 8, 2020 at 8:03 AM Daniel De La Rosa <
> ddelar...@luminanetworks.com> wrote:
>
>> Anil and all,
>>
>> So it turns out that https://jira.opendaylight.org/browse/NETCONF-655 wasn't
>> an issue after all ... more details in the tickets
>>
>> but we still want to merge these two OVSDB issues, come up with a new RC,
>> CSIT and then release sodium SR2
>>
>> https://jira.opendaylight.org/browse/OVSDB-454
>>
>> https://jira.opendaylight.org/browse/OVSDB-428
>>
>> So @Anil Belur  can you merge these gerrits
>> coming from these two OVSDB jira tickets?
>>
>> https://git.opendaylight.org/gerrit/c/ovsdb/+/86257
>>
>> https://git.opendaylight.org/gerrit/c/ovsdb/+/86256
>>
>> https://git.opendaylight.org/gerrit/c/ovsdb/+/86255
>>
>> https://git.opendaylight.org/gerrit/c/ovsdb/+/86270
>>
>> https://git.opendaylight.org/gerrit/c/ovsdb/+/86271
>>
>> so we can pick a new Sodium SR2 RC...
>>
>>
>> Thanks
>>
>>
>> On Thu, Feb 6, 2020 at 9:04 AM Daniel de la Rosa via
>> Lists.Opendaylight.Org > luminanetworks@lists.opendaylight.org> wrote:
>>
>>> Thank you Jamo and Srinivas for signing off these CSIT tests.. so all we
>>> have left is TSC decision on these 4 blockers.. We will review this in our
>>> next TSC meeting but let us if you have any feedback before that..
>>>
>>>
>>>
>>> On Wed, Feb 5, 2020 at 1:23 PM Daniel De La Rosa <
>>> ddelar...@luminanetworks.com> wrote:
>>>
 Team,

 We have picked up Sodium AR # 334 as a new SR2 RC...  so please the
 sodium sr2 new RC on your respective projects


 https://docs.google.com/spreadsheets/d/1CN-ACdIekRKMYRIuREIRALl6S8az7quAcQlRb3KeMJ8/edit?pli=1#gid=931330436

 There was a possible blocker

 https://jira.opendaylight.org/browse/NETCONF-655

 but it looks like this is not a problem with more heap memory. This was
 working with same memory with Sodium but broke with SR1 and SR2 RC... yet
 not a blocker since there is a workaround.

 Also @Robert Varga  please confirm that these issues are
 not blockers for Sodium SR2

 https://jira.opendaylight.org/browse/MDSAL-456

 https://jira.opendaylight.org/browse/OVSDB-454

 https://jira.opendaylight.org/browse/OVSDB-428



 On Tue, Feb 4, 2020 at 10:38 AM Jamo Luhrsen 
 wrote:

> FYI, I used the distribution [0] created in the revert patch and I
> hit an OOM crash. I'm not able to say yet if it's the same
> problem Luis filed [1] or new. This is with a simple netconf
> test to mount 10 devices with large yang schemas.
>
> JamO
>
> [0]
> https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/controller/karaf/0.11.2-SNAPSHOT/karaf-0.11.2-20200204.174523-21.zip
> [1] https://jira.opendaylight.org/browse/CONTROLLER-1928
>
> On 2/4/20 10:32 AM, Daniel De La Rosa wrote:
>
> Thanks Luis and Robert.. let's pick #334 if it is successful tonight
>
>
>
> On Tue, Feb 4, 2020 at 10:18 AM Luis Gomez  wrote:
>
>> FYI, we just reverted the offending patch with the help of Robert:
>>
>> https://git.opendaylight.org/gerrit/#/c/controller/+/87277/
>>
>> We can go ahead and pick the next green sodium AR.
>>
>> BR/Luis
>>
>>
>> On Feb 1, 2020, at 6:53 AM, Robert Varga  wrote:
>>
>> On 30/01/2020 20:21, Daniel De La Rosa wrote:
>>
>> @Robert Varga   and rest of the
>> controller team, do
>> you think that this
>> issue, ttps://jira.opendaylight.org/browse/CONTROLLER-1928
>>  can be solved
>> in
>> the next days?
>>
>>
>> We do have https://git.opendaylight.org/gerrit/c/controller/+/87336,
>> but
>> that 

Re: [controller-dev] [netvirt-dev] [bgpcep-dev] [OpenDaylight TSC] TSC Vote to release latest build # 326 as Sodium SR2

[Abhijit Kumbhare]

Great.

On Tue, Feb 4, 2020 at 10:18 AM Luis Gomez  wrote:

> FYI, we just reverted the offending patch with the help of Robert:
>
> https://git.opendaylight.org/gerrit/#/c/controller/+/87277/
>
> We can go ahead and pick the next green sodium AR.
>
> BR/Luis
>
>
> On Feb 1, 2020, at 6:53 AM, Robert Varga  wrote:
>
> On 30/01/2020 20:21, Daniel De La Rosa wrote:
>
> @Robert Varga   and rest of the
> controller team, do
> you think that this
> issue, ttps://jira.opendaylight.org/browse/CONTROLLER-1928
>  can be solved in
> the next days?
>
>
> We do have https://git.opendaylight.org/gerrit/c/controller/+/87336, but
> that does need careful review.
>
> Bye,
> Robert
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14956): 
https://lists.opendaylight.org/g/controller-dev/message/14956
Mute This Topic: https://lists.opendaylight.org/mt/70252456/21656
Group Owner: controller-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [controller-dev] [bgpcep-dev] [OpenDaylight TSC] TSC Vote to release latest build # 326 as Sodium SR2

[Abhijit Kumbhare]

Thanks Luis. So I guess we need to respin once fixed.

On Wed, Jan 29, 2020 at 1:35 PM Luis Gomez  wrote:

> Yes, I can confirm this patch:
>
> https://git.opendaylight.org/gerrit/#/c/controller/+/87043/
>
> is responsible of these 2 test regressions (green build is without the
> patch):
>
>
> https://jenkins.opendaylight.org/releng/job/controller-csit-3node-rest-clust-cars-perf-ask-only-sodium/
>
> https://jenkins.opendaylight.org/releng/job/controller-csit-1node-akka1-all-sodium/
>
> I will open a ticket for this later.
>
> On top of the above there is a 3rd regression in controller test, but I
> think this could be external (e.g. test env) because it starts at the same
> time (Jan 8th) in all the 3 branches and I do not see any patch going at
> that time:
>
>
> https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-tell-all-neon/
>
> https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-tell-all-sodium/
>
> https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-tell-all-magnesium/
>
> Anyway this last is in the cluster tell-based suite so probably not
> blocking considering this is not default cluster setting.
>
> BR/Luis
>
>
> > On Jan 29, 2020, at 9:05 AM, Luis Gomez  wrote:
> >
> > Regarding the controller test, I saw 2 regressions happening at the same
> time:
> >
> > Ask based perf test does not pass:
> https://jenkins.opendaylight.org/releng/job/controller-csit-3node-rest-clust-cars-perf-ask-only-sodium/
> > Upgrade test fails with OOM and GC memory problems:
> https://jenkins.opendaylight.org/releng/job/controller-csit-1node-akka1-all-sodium/
> >
> > I believe this patch was merged by the time the regression started:
> >
> > https://git.opendaylight.org/gerrit/#/c/controller/+/87043/
> >
> > I will try a revert to confirm and will update here.
> >
> > BR/Luis
> >
> >
> >> On Jan 28, 2020, at 2:45 PM, Daniel de la Rosa <
> ddelar...@luminanetworks.com> wrote:
> >>
> >> Netvirt, BGPCEP and Controller leaders
> >>
> >> Please sign off on the results for your projects ASAP so we can release
> sodium SR2 as soon as possible.
> >>
> >> [2]
> https://docs.google.com/spreadsheets/d/1CN-ACdIekRKMYRIuREIRALl6S8az7quAcQlRb3KeMJ8/edit?pli=1#gid=2145734982
> >>
> >>
> >> thanks
> >>
> >> -- Forwarded message -
> >> From: Abhijit Kumbhare 
> >> Date: Tue, Jan 28, 2020 at 2:04 PM
> >> Subject: [OpenDaylight TSC] TSC Vote to release latest build # 326 as
> Sodium SR2
> >> To: tsc 
> >>
> >>
> >> Hello TSC members,
> >>
> >> Please vote -1, 0 or +1 to release the latest build #326 as the Sodium
> SR2 subject to successful vetting of the CSIT results [2] by the projects.
> >>
> >> Most of the relevant information is in Jamo's email [0]. Please check
> the autorelease build [1] and the CSIT results [2]. Please note that Daniel
> will be asking for projects to vet the results in parallel.
> >>
> >> Doing this over email rather than confluence so we can get faster
> responses in this particular case.
> >>
> >> Thanks,
> >> Abhijit
> >>
> >> [0] Jamo's email on Sodium SR 2
> >> [1]
> https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-sodium-mvn35-openjdk8/326/
> >> [2]
> https://docs.google.com/spreadsheets/d/1CN-ACdIekRKMYRIuREIRALl6S8az7quAcQlRb3KeMJ8/edit?pli=1#gid=2145734982
> >>
> >>
> >>
> >>
> >> --
> >> Daniel de la Rosa
> >> Customer Support Manager
> >> Lumina Networks Inc.
> >> e: ddelar...@luminanetworks.com
> >> m:  +1 408 7728120
> >>
> >
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14947): 
https://lists.opendaylight.org/g/controller-dev/message/14947
Mute This Topic: https://lists.opendaylight.org/mt/70246269/21656
Group Owner: controller-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [controller-dev] [bgpcep-dev] [OpenDaylight TSC] TSC Vote to release latest build # 326 as Sodium SR2

[Abhijit Kumbhare]

Thanks Luis!

On Tue, Jan 28, 2020 at 8:20 PM Luis Gomez  wrote:

> OK, it turned out the issue is nothing to do with global-jjb update but a
> change in 3rd party python library setuptools. We will try a patch to pin
> the working version.
>
> BR/Luis
>
>
> > On Jan 28, 2020, at 3:47 PM, Luis Gomez  wrote:
> >
> > FYI I took a look and BGPCEP job is failing because it is not possible
> to install exabgp 3.4.16:
> >
> > pip install exabgp==3.4.16
> > ERROR: Package 'setuptools' requires a different Python: 2.7.12 not in
> '>=3.5'' should be empty.
> >
> > I believe this started to happen after last global-jjb update:
> >
> > https://git.opendaylight.org/gerrit/#/c/releng/builder/+/86856
> >
> > BR/Luis
> >
> >
> >> On Jan 28, 2020, at 2:45 PM, Daniel de la Rosa <
> ddelar...@luminanetworks.com> wrote:
> >>
> >> Netvirt, BGPCEP and Controller leaders
> >>
> >> Please sign off on the results for your projects ASAP so we can release
> sodium SR2 as soon as possible.
> >>
> >> [2]
> https://docs.google.com/spreadsheets/d/1CN-ACdIekRKMYRIuREIRALl6S8az7quAcQlRb3KeMJ8/edit?pli=1#gid=2145734982
> >>
> >>
> >> thanks
> >>
> >> -- Forwarded message -
> >> From: Abhijit Kumbhare 
> >> Date: Tue, Jan 28, 2020 at 2:04 PM
> >> Subject: [OpenDaylight TSC] TSC Vote to release latest build # 326 as
> Sodium SR2
> >> To: tsc 
> >>
> >>
> >> Hello TSC members,
> >>
> >> Please vote -1, 0 or +1 to release the latest build #326 as the Sodium
> SR2 subject to successful vetting of the CSIT results [2] by the projects.
> >>
> >> Most of the relevant information is in Jamo's email [0]. Please check
> the autorelease build [1] and the CSIT results [2]. Please note that Daniel
> will be asking for projects to vet the results in parallel.
> >>
> >> Doing this over email rather than confluence so we can get faster
> responses in this particular case.
> >>
> >> Thanks,
> >> Abhijit
> >>
> >> [0] Jamo's email on Sodium SR 2
> >> [1]
> https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-sodium-mvn35-openjdk8/326/
> >> [2]
> https://docs.google.com/spreadsheets/d/1CN-ACdIekRKMYRIuREIRALl6S8az7quAcQlRb3KeMJ8/edit?pli=1#gid=2145734982
> >>
> >>
> >>
> >>
> >> --
> >> Daniel de la Rosa
> >> Customer Support Manager
> >> Lumina Networks Inc.
> >> e: ddelar...@luminanetworks.com
> >> m:  +1 408 7728120
> >>
> >
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14944): 
https://lists.opendaylight.org/g/controller-dev/message/14944
Mute This Topic: https://lists.opendaylight.org/mt/70230612/21656
Group Owner: controller-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [controller-dev] [OpenDaylight TSC] Micro-distribution: Follow Up from TWS

[Abhijit Kumbhare]

Tejas & folks,

Casey has moved the proposal page to Confluence:

https://wiki.lfnetworking.org/x/ngDTAQ

Confluence allows page comments. If you would like to add your comments on
the proposal - you can add them there.

(BTW Thanks Casey!)

Regards,
Abhijit

On Wed, Jan 22, 2020 at 10:34 AM Tejas Nevrekar 
wrote:

> Hi all,
>
> Just bringing here the discussion we had in the TWS this Monday.
>
> Robert, as some of us were proposing in the TWS we would like to do a POC
> level effort to create a netconf micro-distribution using lighty as a first
> step in using lighty in ODL. I would like to know from the Lighty team if
> there are any known gaps in the proposed lighty modules given here (
> https://wiki.opendaylight.org/view/Project_Proposals:Lighty) that will
> make it hard/unfeasible to realize a netconf micro-distribution.
>
> Also when it comes to use cases, in the Mg DDF Luis and I had outlined a
> few use cases that we wanted to eventually solve with this solution -
> https://wiki.lfnetworking.org/download/attachments/19006711/ODL-Scale%20Mg.pdf?version=1=1569500298000=v2
>
> Thanks,
>
> Tejas. S. Nevrekar
> Mobile: +91-99805 31339
> Bangalore, INDIA.
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14933): 
https://lists.opendaylight.org/g/controller-dev/message/14933
Mute This Topic: https://lists.opendaylight.org/mt/70014499/21656
Group Owner: controller-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[controller-dev] TWS meeting slot time change to Mondays 9 am Pacific

[Abhijit Kumbhare]

Folks,

The TWS call time slot has been Mondays 10 am Pacific since the beginning
of OpenDaylight. At the same time we voted and agreed the timing for the
Micro-distribution meeting will be Mondays 9 am Pacific. This topic is very
much similar to a potential TWS topic and we have not had a TWS meeting for
some time. Hence in today's TSC meeting we decided the following:

   - For the near term (while we have no other TWS topic) we will discuss
   the Micro-distribution topic in the TWS meetings.
   - We will move the TWS meeting to Mondays 9 am Pacific (instead of 10 am
   Pacific).

Casey will send the update on the call zoom info. We will have this coming
Monday the call at 9 am Pacific as the Micro-distribution team had already
discussed about meeting at this time on coming Monday.

Regards,
Abhijit
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14919): 
https://lists.opendaylight.org/g/controller-dev/message/14919
Mute This Topic: https://lists.opendaylight.org/mt/68524070/21656
Group Owner: controller-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [controller-dev] 答复: Problem: ODL Neon archetype repo missing?

[Abhijit Kumbhare]

Sure - we can discuss it on today's call.

On Thu, Jun 20, 2019 at 3:38 AM Robert Varga  wrote:

> On 20/06/2019 04:39, 金恺文 wrote:
> > Hi everyone，
>
> Hello,
>
> > Sorry I put the wrong link in the previous mail, I followed the
> > neon-version guide but gave the boron-version link
> >
> >
> >
> > So here is my question after correction:
> >
> >
> >
> > I was trying to create an Example project following this developer
> > guide,
> >
> https://docs.opendaylight.org/en/stable-neon/developer-guide/developing-apps-on-the-opendaylight-controller.html
> ,
> > but the archetype repository seemed not to exist.
> >
> > I did
> >
> > *mvn archetype:generate
> > **-**DarchetypeGroupId**=**org**.**opendaylight**.**archetypes
> > **-**DarchetypeArtifactId**=**opendaylight**-**startup**-**archetype \*
> >
> > *-**DarchetypeCatalog**=**remote
> > **-**DarchetypeVersion**=**1.0**.**0**-**SNAPSHOT*
> >
> >
> >
> > Then I got this error from maven:
> >
> > *Failed to execute goal
> > org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate
> > (default-cli) on project standalone-pom: The desired archetype does not
> > exist
> >
> (org.opendaylight.archetypes:opendaylight-startup-archetype:1.1.0-SNAPSHOT)*
> >
> > I confirm that I have changed the settings.xml as required, so is there
> > any other repository where the archetypes are hosted?
> >
> > Hope someone could answer my amateur question J, thanks
>
> The archetypes project is sorrily out of date to the point of its merge
> jobs not being able to complete, so the -SNAPSHOT versions were not
> refreshed and expired from nexus.
>
> Abhijit, can we discuss the way forward there at today's TSC call?
>
> Thanks,
> Robert
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Signing Off

[Abhijit Kumbhare]

Wish you good luck Ryan! I have always appreciated your efforts,
contributions as well as opinions over the last 4 years. I am sure the
whole OpenDaylight community feels the same as well. Also your kernel
projects meeting minutes have been a staple of my Tuesday mornings.

I am sure we will continue to run into each other and probably work
together again in future.

Have fun in your next job!

Abhijit

On Mon, Aug 27, 2018 at 2:02 PM Ryan Goulding 
wrote:

> Hi ODL Community,
>
>
> I have decided to make a career transition to an opportunity I could not
> pass up, and will no longer contribute to ODL after this week.  This past
> 4 years has been great;  I saw this entire community grow, thrive and
> mature, and I am very proud of what we collectively built.  I have
> learned so much from everyone regarding technology and business fronts, and
> I am grateful to all of you.
>
>
> I wish you all the best of luck going forward.  Stay in touch.
>
>
> Best Regards,
>
> Ryan
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [mdsal-dev] Clustering Call

[Abhijit Kumbhare]

Hopefully its not too early in the day. Looping in some existing/potential
consumers of clustering in case they want to contribute in fixing the
issues and plan to attend.

On Thu, Jun 14, 2018 at 10:19 AM Jamo Luhrsen  wrote:

> We (integration team) are willing to give up our weekly meeting
> which is the hour after the TSC to do this cluster sync up.
>
> Assuming this will only be for some number of months we can count
> on one hand *crossing fingers*
>
> JamO
>
> On 6/14/18 10:13 AM, Ariel Adam wrote:
> > Can't be to late due to India and Europ.
> > Can't be to early due to the west cost :-).
> > How about same time as the Netvirt meeting (which happens on Tuesday) on
> Wednesday?
> >
> > Thanks.
> >
> > On Thu, Jun 14, 2018 at 8:06 PM, Casey Cain  > wrote:
> >
> > Hi, everyone.
> >
> > It sounds like we need to move the call for the Clustering Hackers
> meeting.
> >
> > Is there a suggested time that works best for everyone?
> >
> > Best,
> > Casey Cain
> > Technical Program Manager
> > Linux Foundation
> > _
> > IRC - CaseyLF
> > Skype - wrathwolfk
> > WeChat - okaru6
> >
> >
> ___
> mdsal-dev mailing list
> mdsal-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/mdsal-dev
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL data store with etcd or something else"

[Abhijit Kumbhare]

True - that is the reason I said we should have a TWS session on this
sometime (may be May 7?).

On Thu, Apr 26, 2018 at 11:07 AM, Robert Varga  wrote:

> On 03/04/18 16:44, Michael Vorburger wrote:
> > On Thu, Mar 29, 2018 at 7:10 AM, Muthukumaran K
> > >
> wrote:
> >
> > Is there any summary of points discussed during the meeting on this
> > topic ?
> >
> >
> > https://photos.app.goo.gl/XeI4b2co7pisR4Xk2 ;-)
>
> +TSC
>
> I think the TSC should take
> https://lh3.googleusercontent.com/RgvovkbCtOocRPSClCQcKYChdChtxR
> vyZXwrhT-BvEMGB7VL-pOIAM9hfDnU1Uq9EFHtRfxXfeLtbm1S3Cqi97ZzVkaRm6KJ2al-
> ONt2bUQv4G5RtEjugufhtmnB38ijwq3a-H3K9TI=w667-h1185-no
> and turn it into actionable items and asks towards the LFN, so the
> brainstorming we did there does not fizzle into nothingness.
>
> Regads,
> Robert
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL data store with etcd or something else"

[Abhijit Kumbhare]

We are in Echo Park

On Wed, Mar 28, 2018 at 9:38 AM Abhijit Kumbhare <abhijitk...@gmail.com>
wrote:

> Ok - let’s meet there then. That is next to the room where we had our
> sessions (Echo Park), right?
>
> On Wed, Mar 28, 2018 at 9:35 AM Michael Vorburger <vorbur...@redhat.com>
> wrote:
>
>> I can come, but did not understand which room... Shall we just meet in
>> that developer area room with the tables?
>>
>> On Wed, 28 Mar 2018, 09:31 Casey Cain, <cc...@linuxfoundation.org> wrote:
>>
>>> Here is the Zoom info.
>>>
>>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/378977881
>>>
>>> Or iPhone one-tap :
>>> US: +16699006833,,378977881# or +16465588656,,378977881#
>>> Or Telephone:
>>> Dial(for higher quality, dial a number based on your current location):
>>> US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or
>>> +1 855 880 1246 (Toll Free)
>>> Meeting ID: 378 977 881
>>> International numbers available:
>>> https://zoom.us/zoomconference?m=3N5Hunw-pq1P_JpmUXATbXXWSnyHqsBy
>>>
>>>
>>> On Wed, Mar 28, 2018 at 9:28 AM, Andre Fredette <afrede...@redhat.com>
>>> wrote:
>>>
>>>> Is this confirmed?
>>>>
>>>> Thanks,
>>>> Andre
>>>>
>>>> On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare <
>>>> abhijitk...@gmail.com> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> Resurrecting an old thread that we have talked about for a while. I
>>>>> believe some folks were planning to discuss this at the DDF but for some
>>>>> reason there was no topic proposed on this. Chris, Robert and I were
>>>>> discussing having a meeting about this sometime tomorrow morning - say at
>>>>> 10 am. Chris will be able to arrange a room for us. We can ask Casey to
>>>>> have a Zoom session. It will be great if you guys can attend - at least
>>>>> Robert, Tom, Michael, Stephen, Muthu, etc.
>>>>>
>>>>> Thanks,
>>>>> Abhijit
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 1, 2017 at 11:22 PM, Muthukumaran K <
>>>>> muthukumara...@ericsson.com> wrote:
>>>>>
>>>>>> Thanks for the explanation Robert.
>>>>>>
>>>>>> When we refer access pattern and shard layout, I assume that it is in
>>>>>> context of a given transaction owned by an application - please correct 
>>>>>> me
>>>>>> if I am wrong.
>>>>>>
>>>>>> As a detour, the reference to transactions leads to a bunch of
>>>>>> questions on how MD-SAL transactions - as we know in context of IMDS, 
>>>>>> could
>>>>>> map on to external backend for a given shard (which CDT enables)
>>>>>>
>>>>>> For few transaction capabilities which are inherent in IMDS, there
>>>>>> may not be equivalent concept/support in an external backend of choice. 
>>>>>> For
>>>>>> example, concept like Transaction Chain.
>>>>>>
>>>>>> Other implementation-specific aspects of transaction could also vary
>>>>>> drastically - for example,
>>>>>> a) Snapshotting+MVCC as "I" of ACID is applicable for IMDS - but may
>>>>>> not be true in case of Etcd / Cassandra - this mismatch may not have 
>>>>>> deeper
>>>>>> ramifications to the end-user
>>>>>> b) strong-consistency for writes may be a do-it-yourself if backend
>>>>>> choice is Cassandra whereas its ingrained in IMDS
>>>>>>
>>>>>> Does this essentially mean that based on choice of backend, some
>>>>>> concepts of transactions could be just no-op/ will be thrown with an
>>>>>> unsupported exception (eg. transaction-chain) to manage the uniformity of
>>>>>> broker contracts?
>>>>>>
>>>>>> Regards
>>>>>> Muthu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Original Message-
>>>>>> From: Robert Varga [mailto:n...@hq.sk]
>>>>>> Sent: Tuesday, December 27, 2016 9:10 PM
>>>>>> To: Muthukumaran K <muthukumar

Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL data store with etcd or something else"

[Abhijit Kumbhare]

Ok - let’s meet there then. That is next to the room where we had our
sessions (Echo Park), right?

On Wed, Mar 28, 2018 at 9:35 AM Michael Vorburger <vorbur...@redhat.com>
wrote:

> I can come, but did not understand which room... Shall we just meet in
> that developer area room with the tables?
>
> On Wed, 28 Mar 2018, 09:31 Casey Cain, <cc...@linuxfoundation.org> wrote:
>
>> Here is the Zoom info.
>>
>> Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/378977881
>>
>> Or iPhone one-tap :
>> US: +16699006833,,378977881# or +16465588656,,378977881#
>> Or Telephone:
>> Dial(for higher quality, dial a number based on your current location):
>> US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or
>> +1 855 880 1246 (Toll Free)
>> Meeting ID: 378 977 881
>> International numbers available:
>> https://zoom.us/zoomconference?m=3N5Hunw-pq1P_JpmUXATbXXWSnyHqsBy
>>
>>
>> On Wed, Mar 28, 2018 at 9:28 AM, Andre Fredette <afrede...@redhat.com>
>> wrote:
>>
>>> Is this confirmed?
>>>
>>> Thanks,
>>> Andre
>>>
>>> On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare <abhijitk...@gmail.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Resurrecting an old thread that we have talked about for a while. I
>>>> believe some folks were planning to discuss this at the DDF but for some
>>>> reason there was no topic proposed on this. Chris, Robert and I were
>>>> discussing having a meeting about this sometime tomorrow morning - say at
>>>> 10 am. Chris will be able to arrange a room for us. We can ask Casey to
>>>> have a Zoom session. It will be great if you guys can attend - at least
>>>> Robert, Tom, Michael, Stephen, Muthu, etc.
>>>>
>>>> Thanks,
>>>> Abhijit
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Jan 1, 2017 at 11:22 PM, Muthukumaran K <
>>>> muthukumara...@ericsson.com> wrote:
>>>>
>>>>> Thanks for the explanation Robert.
>>>>>
>>>>> When we refer access pattern and shard layout, I assume that it is in
>>>>> context of a given transaction owned by an application - please correct me
>>>>> if I am wrong.
>>>>>
>>>>> As a detour, the reference to transactions leads to a bunch of
>>>>> questions on how MD-SAL transactions - as we know in context of IMDS, 
>>>>> could
>>>>> map on to external backend for a given shard (which CDT enables)
>>>>>
>>>>> For few transaction capabilities which are inherent in IMDS, there may
>>>>> not be equivalent concept/support in an external backend of choice. For
>>>>> example, concept like Transaction Chain.
>>>>>
>>>>> Other implementation-specific aspects of transaction could also vary
>>>>> drastically - for example,
>>>>> a) Snapshotting+MVCC as "I" of ACID is applicable for IMDS - but may
>>>>> not be true in case of Etcd / Cassandra - this mismatch may not have 
>>>>> deeper
>>>>> ramifications to the end-user
>>>>> b) strong-consistency for writes may be a do-it-yourself if backend
>>>>> choice is Cassandra whereas its ingrained in IMDS
>>>>>
>>>>> Does this essentially mean that based on choice of backend, some
>>>>> concepts of transactions could be just no-op/ will be thrown with an
>>>>> unsupported exception (eg. transaction-chain) to manage the uniformity of
>>>>> broker contracts?
>>>>>
>>>>> Regards
>>>>> Muthu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: Robert Varga [mailto:n...@hq.sk]
>>>>> Sent: Tuesday, December 27, 2016 9:10 PM
>>>>> To: Muthukumaran K <muthukumara...@ericsson.com>; Colin Dixon <
>>>>> co...@colindixon.com>; Shrenik Jain <shrenik.j...@research.iiit.ac.in>
>>>>> Cc: integration-...@lists.opendaylight.org <d...@lists.opendaylight.org>;
>>>>> controller-dev <controller-dev@lists.opendaylight.org>;
>>>>> mdsal-...@lists.opendaylight.org; intern-ad...@opendaylight.org
>>>>> Subject: Re: [controller-dev] Interested in Contribution : "Replacing
>>>>> the MD-SAL data s

[controller-dev] Topic : "Replacing the MD-SAL data store with etcd or something else"

[Abhijit Kumbhare]

Hi folks,

Resurrecting an old thread that we have talked about for a while. I believe
some folks were planning to discuss this at the DDF but for some reason
there was no topic proposed on this. Chris, Robert and I were discussing
having a meeting about this sometime tomorrow morning - say at 10 am. Chris
will be able to arrange a room for us. We can ask Casey to have a Zoom
session. It will be great if you guys can attend - at least Robert, Tom,
Michael, Stephen, Muthu, etc.

Thanks,
Abhijit




On Sun, Jan 1, 2017 at 11:22 PM, Muthukumaran K  wrote:

> Thanks for the explanation Robert.
>
> When we refer access pattern and shard layout, I assume that it is in
> context of a given transaction owned by an application - please correct me
> if I am wrong.
>
> As a detour, the reference to transactions leads to a bunch of questions
> on how MD-SAL transactions - as we know in context of IMDS, could map on to
> external backend for a given shard (which CDT enables)
>
> For few transaction capabilities which are inherent in IMDS, there may not
> be equivalent concept/support in an external backend of choice. For
> example, concept like Transaction Chain.
>
> Other implementation-specific aspects of transaction could also vary
> drastically - for example,
> a) Snapshotting+MVCC as "I" of ACID is applicable for IMDS - but may not
> be true in case of Etcd / Cassandra - this mismatch may not have deeper
> ramifications to the end-user
> b) strong-consistency for writes may be a do-it-yourself if backend choice
> is Cassandra whereas its ingrained in IMDS
>
> Does this essentially mean that based on choice of backend, some concepts
> of transactions could be just no-op/ will be thrown with an unsupported
> exception (eg. transaction-chain) to manage the uniformity of broker
> contracts?
>
> Regards
> Muthu
>
>
>
>
> -Original Message-
> From: Robert Varga [mailto:n...@hq.sk]
> Sent: Tuesday, December 27, 2016 9:10 PM
> To: Muthukumaran K ; Colin Dixon <
> co...@colindixon.com>; Shrenik Jain 
> Cc: integration-...@lists.opendaylight.org ;
> controller-dev ;
> mdsal-...@lists.opendaylight.org; intern-ad...@opendaylight.org
> Subject: Re: [controller-dev] Interested in Contribution : "Replacing the
> MD-SAL data store with etcd"
>
> On 12/27/2016 11:38 AM, Muthukumaran K wrote:
> > Hi Robert,
> >
> > Looking at
> > https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/sr
> > c/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeShardingService.
> > java
> >
> > Few clarifications:
> > For same prefix duplicate producers are not allowed - this is
> > understandable. But there is a possibility that two distinct
> > producers/shards can have overlapping prefixes - if this is allowed,
> > would not there be a scenario wherein we could end up with a superset
> > shard and subset shard
> >
> > Eg. Let's assume there is a subtree whose prefix is /a/b/c/d mapped to
> shard 1 and another /a/b/c/d/e/f mapped to another shard.
> > In other words, we can have recursive shards (hypothetical worst case
> could be that these recursive shards could have their own backend
> instances).
> > Would this not lead to relatively complex read and write routing
> implementations? Are such overlaps prevented by Sharding service contracts ?
>
> This is allowed and the two shards have a parent/child relationship, where
> the parent understands that it has a subordinate shard. There can (in
> theory) be infinite nesting, although I am not sure if the implementation
> handles more than one level.
>
> As for complexity of data access... it is *relatively* complex, but all it
> really boils down to is a recursive scatter/gather algorithm, where the
> superior shard delegates parts of the request to its subordinates and
> merges the responses -- which is pretty much bread-and-butter when dealing
> with tree-based structures.
>
> In any case, while possible, we envision that most applications will only
> talk to leaf shards, hence scatter/gather will not kick in. The cost of
> determining which shard is the apex for a producer is paid when the
> producer is instantiated, hence the steady-state cost should typically be
> zero.
>
> If the application access pattern and sharding layout do not align, you
> will get sucky performance, similar to what you get if you try to write to
> multiple module-based shards today. But that is a deployment-time
> engineering and application co-existence issue, which we cannot solve at
> the infrastructure layer.
>
> Regards,
> Robert
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org

Re: [controller-dev] YourKit Profiler License

[Abhijit Kumbhare]

Actually adding them this time .

On Wed, Feb 14, 2018 at 3:24 PM, Abhijit Kumbhare <abhijitk...@gmail.com>
wrote:

> That's good to know - including discuss and release as not all the
> relevant folks maybe on the dev mailing list.
>
> On Wed, Feb 14, 2018 at 1:49 PM, Casey Cain <cc...@linuxfoundation.org>
> wrote:
>
>> Hello members of the dev community.
>>
>> I'm happy to announce that the ODL community licence for YourKit Profiler
>> has been renewed.
>> https://www.yourkit.com/m/manage?t=YDZC2QOT9873VIBCL3B115CANN2
>>
>> I apologize in our delay to resolve this issue. If you have any
>> questions, please let me know.
>>
>> Best,
>> Casey Cain
>> Technical Program Manager
>> Linux Foundation
>> _
>> IRC - CaseyODL
>> Skype - wrathwolfk
>> WeChat - okaru6
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] YourKit Profiler License

[Abhijit Kumbhare]

That's good to know - including discuss and release as not all the relevant
folks maybe on the dev mailing list.

On Wed, Feb 14, 2018 at 1:49 PM, Casey Cain 
wrote:

> Hello members of the dev community.
>
> I'm happy to announce that the ODL community licence for YourKit Profiler
> has been renewed.
> https://www.yourkit.com/m/manage?t=YDZC2QOT9873VIBCL3B115CANN2
>
> I apologize in our delay to resolve this issue. If you have any questions,
> please let me know.
>
> Best,
> Casey Cain
> Technical Program Manager
> Linux Foundation
> _
> IRC - CaseyODL
> Skype - wrathwolfk
> WeChat - okaru6
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

[Abhijit Kumbhare]

Just commenting on code in a mature project depending on code in non-mature
project & nothing else:

I don't think it was written in the project lifecycle rules that some code
in a mature project cannot depend on some code in incubation or a bootstrap
project. By that logic we would never be able to have the following type of
new functionality added in ODL:

   - that some mature offset 1 or 2 projects desire
   - the new functionality either deserves a new offset 0 project or
   logically needs to go into an existing offset 0 incubation/bootstrap
   project

Also there is at least one instance in ODL where we have some mature
projects (NetVirt, VTN, GBP to name a few) depending on non-mature project
like OpenFlow Plugin (which is in bootstrap state).




On Mon, Oct 23, 2017 at 12:23 PM, Robert Varga  wrote:

> On 23/10/17 21:13, Tom Pantelis wrote:
> > On Mon, Oct 23, 2017 at 2:34 PM, Robert Varga  > > wrote:
> >
> > On 23/10/17 14:37, Tom Pantelis wrote:
> > > Or we get infrautils promoted to "mature" to get around the red
> tape.
> > > What would that take? ...
> >
> > A Graduation Review. Unfortunately
> > https://www.opendaylight.org/project-lifecycle-releases
> > 
> disappeared
> > somewhere (Casey, do you know where?), but it includes things like:
> > - clear scope
> > - history of following the mature release cycle
> > etc.
> >
> >
> > If it disappeared then how important can it be now :) ...  These rules
> > and bureaucracy were put into place a while ago when ODL had a lot more
> > participation. Along with Michael, I question whether it's really
> > relevant anymore...
>
> It is part of our governance and how OpenDaylight is set up. If things
> are not relevant anymore, then our governance needs to change -- and
> that is something the Board/TSC have to tackle *first*, we cannot just
> start ignoring it.
>
> I do not agree with this particular piece being irrelevant -- it is just
> not convenient.
>
> I think everyone knows where I stand on convenience vs. long-term
> sustainability :) and that stance is held supported by many scars.
>
> Regards,
> Robert
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [mdsal-dev] [openflowplugin-dev] Fwd: Bug 9038 - IllegalStateException: Attempted to close chain with outstanding transaction PingPongTransaction at org.opendaylight.openflowplugi

[Abhijit Kumbhare]

In-line.

On Tue, Sep 19, 2017 at 7:24 AM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> On Fri, Sep 15, 2017 at 6:42 PM, Abhijit Kumbhare <abhijitk...@gmail.com>
> wrote:
>
>> Thanks Michael! Looks like Luis is running test-openflowplugin-core on
>> the patch. Also I understand one of the 3 exceptions is fixed - there are
>> the other two exceptions still remaining. With one major exception fixed,
>> does this mean the priority can be reduced from blocker to critical?
>>
>
> Abhijit, IMHO we would be causing less confusion ;) if we closed 9038
> (after it's gone into master also, that was forgotten...) and then had 2
> separate new bugs for those other exceptions.
>

Sure - no problem.


>
> Sridhar, were you going to open those 2 other new bugs? It doesn't matter
> IMHO if you don't have the environment anymore to be able to provide more
> logs in the short term - at least have the issues, so that the openfllow
> plugin team can start pondering what to do about those, some time...
>
>
>>
>> On Fri, Sep 15, 2017 at 5:28 AM, Michael Vorburger <vorbur...@redhat.com>
>> wrote:
>>
>>> On Fri, Sep 8, 2017 at 8:28 AM, Jozef Bacigál <
>>> jozef.baci...@pantheon.tech> wrote:
>>>
>>>> Thanks Michael, thanks for information. :)
>>>>
>>>>
>>>>
>>>> I do investigations further for the Illegal state bug.
>>>>
>>>
>>> Jozef, Abhijit, Anil: Have you seen https://bugs.opendaylight.org/
>>> show_bug.cgi?id=9038#c19 - great news - thanks a lot, Sridhar and
>>> everyone involved!
>>>
>>> So... will you merge https://git.opendaylight.org/gerrit/#/c/62674/6
>>> ASAP, cherry-pick it from stable/carbon to stable/nitrogen and master,
>>> and... done!
>>>
>>>
>>>> But at least we got some issue solved :)
>>>>
>>>>
>>>>
>>>> Jozef
>>>>
>>>>
>>>>
>>>> P.S.: Let you know if something new
>>>>
>>>>
>>>>
>>>> *From:* Michael Vorburger [mailto:vorbur...@redhat.com]
>>>> *Sent:* Thursday, September 7, 2017 3:07 PM
>>>> *To:* Jozef Bacigál <jozef.baci...@pantheon.tech>; Anil Vishnoi <
>>>> vishnoia...@gmail.com>; Vishnoi, Anil <avish...@brocade.com>
>>>> *Cc:* Robert Varga <n...@hq.sk>; Tomáš Slušný
>>>> <tomas.slu...@pantheon.tech>; Abhijit Kumbhare <abhijitk...@gmail.com>;
>>>> openflowplugin-...@lists.opendaylight.org;
>>>> controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org
>>>> *Subject:* Re: [mdsal-dev] [openflowplugin-dev] Fwd: Bug 9038 -
>>>> IllegalStateException: Attempted to close chain with outstanding
>>>> transaction PingPongTransaction at org.opendaylight.openflowplugi
>>>> n.impl.device.TransactionChainManager.createTxChain
>>>>
>>>>
>>>>
>>>> All,
>>>>
>>>>
>>>>
>>>> On Wed, Sep 6, 2017 at 7:26 PM, Michael Vorburger <vorbur...@redhat.com>
>>>> wrote:
>>>>
>>>> On Wed, Sep 6, 2017 at 4:34 PM, Michael Vorburger <vorbur...@redhat.com>
>>>> wrote:
>>>>
>>>> On Wed, Sep 6, 2017 at 3:59 PM, Jozef Bacigál <
>>>> jozef.baci...@pantheon.tech> wrote:
>>>>
>>>> HI Michael,
>>>>
>>>> are you able to test it on this patch [1] ? Or it needed to be merged ?
>>>>
>>>> Jozef - thanks a lot! I'll discuss with Daniel to understand how
>>>> easy/hard it would be to get a carbon RPM with this, and let you know ASAP.
>>>>
>>>>
>>>>
>>>> Jozef, FYI we've just been able to get a new full ODL dist build + RPM
>>>> incl. this (unmerge) change, and will re-run this through our scale test
>>>> environment ASAP, and let you know how it looks.
>>>>
>>>>
>>>>
>>>> There is Good and Bad news - which one do you want first? ;-)
>>>>
>>>> The Good: I’m (very) happy to hereby confirm that on a re-test of a
>>>> custom distribution of latest (yesterday's) carbon/stable together with
>>>> c/62674/5 (NB Patch Set 5; it’s still WIP) pulled in, we do not see
>>>> https://bugs.opendaylight.org/show_bug.cgi?id=9034 (OOM due to huge
>>>> Map in ShardDataTree) anymore! This is great. NB: It may have been c/62674
>>>> or anything else t

Re: [controller-dev] [mdsal-dev] [openflowplugin-dev] Fwd: Bug 9038 - IllegalStateException: Attempted to close chain with outstanding transaction PingPongTransaction at org.opendaylight.openflowplugi

[Abhijit Kumbhare]

Thanks Michael! Looks like Luis is running test-openflowplugin-core on the
patch. Also I understand one of the 3 exceptions is fixed - there are the
other two exceptions still remaining. With one major exception fixed, does
this mean the priority can be reduced from blocker to critical?

On Fri, Sep 15, 2017 at 5:28 AM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> On Fri, Sep 8, 2017 at 8:28 AM, Jozef Bacigál <jozef.baci...@pantheon.tech
> > wrote:
>
>> Thanks Michael, thanks for information. :)
>>
>>
>>
>> I do investigations further for the Illegal state bug.
>>
>
> Jozef, Abhijit, Anil: Have you seen https://bugs.opendaylight.org/
> show_bug.cgi?id=9038#c19 - great news - thanks a lot, Sridhar and
> everyone involved!
>
> So... will you merge https://git.opendaylight.org/gerrit/#/c/62674/6
> ASAP, cherry-pick it from stable/carbon to stable/nitrogen and master,
> and... done!
>
>
>> But at least we got some issue solved :)
>>
>>
>>
>> Jozef
>>
>>
>>
>> P.S.: Let you know if something new
>>
>>
>>
>> *From:* Michael Vorburger [mailto:vorbur...@redhat.com]
>> *Sent:* Thursday, September 7, 2017 3:07 PM
>> *To:* Jozef Bacigál <jozef.baci...@pantheon.tech>; Anil Vishnoi <
>> vishnoia...@gmail.com>; Vishnoi, Anil <avish...@brocade.com>
>> *Cc:* Robert Varga <n...@hq.sk>; Tomáš Slušný <tomas.slu...@pantheon.tech>;
>> Abhijit Kumbhare <abhijitk...@gmail.com>; openflowplugin-dev@lists.opend
>> aylight.org; controller-dev@lists.opendaylight.org;
>> mdsal-...@lists.opendaylight.org
>> *Subject:* Re: [mdsal-dev] [openflowplugin-dev] Fwd: Bug 9038 -
>> IllegalStateException: Attempted to close chain with outstanding
>> transaction PingPongTransaction at org.opendaylight.openflowplugi
>> n.impl.device.TransactionChainManager.createTxChain
>>
>>
>>
>> All,
>>
>>
>>
>> On Wed, Sep 6, 2017 at 7:26 PM, Michael Vorburger <vorbur...@redhat.com>
>> wrote:
>>
>> On Wed, Sep 6, 2017 at 4:34 PM, Michael Vorburger <vorbur...@redhat.com>
>> wrote:
>>
>> On Wed, Sep 6, 2017 at 3:59 PM, Jozef Bacigál <
>> jozef.baci...@pantheon.tech> wrote:
>>
>> HI Michael,
>>
>> are you able to test it on this patch [1] ? Or it needed to be merged ?
>>
>> Jozef - thanks a lot! I'll discuss with Daniel to understand how
>> easy/hard it would be to get a carbon RPM with this, and let you know ASAP.
>>
>>
>>
>> Jozef, FYI we've just been able to get a new full ODL dist build + RPM
>> incl. this (unmerge) change, and will re-run this through our scale test
>> environment ASAP, and let you know how it looks.
>>
>>
>>
>> There is Good and Bad news - which one do you want first? ;-)
>>
>> The Good: I’m (very) happy to hereby confirm that on a re-test of a
>> custom distribution of latest (yesterday's) carbon/stable together with
>> c/62674/5 (NB Patch Set 5; it’s still WIP) pulled in, we do not see
>> https://bugs.opendaylight.org/show_bug.cgi?id=9034 (OOM due to huge Map
>> in ShardDataTree) anymore! This is great. NB: It may have been c/62674 or
>> anything else that went in recently (anywhere incl. Bug 9028, dunno if that
>> could have helped for this?) which did the trick, but it works now, so
>> great! FYI this has been verified by both "wow, now it didn't blew up
>> anymore with OOM" as well as confirmed via HPROF analysis through MAT
>> (which now also revealed new Bug 9114; but that's another story). I'll
>> therefore close blocker Bug 9034 as soon as you've agreed a final version
>> of c/62674 and merged it (into carbon, nitrogen and master).
>>
>> The FYI: c/62674/5 does fix https://bugs.opendaylight.org/
>> show_bug.cgi?id=9070, so I'll also close that after you merge.
>>
>>
>>
>> The Bad: The https://bugs.opendaylight.org/show_bug.cgi?id=9038
>> "IllegalStateException: Attempted to close chain with outstanding
>> transaction PingPongTransaction" still appears in logs - sorry. So c/62674/5
>> *DOES NOT* fix blocker Bug 9038. You can also find related information
>> on the new attachment on umbrella https://bugs.opendaylight.org/
>> show_bug.cgi?id=9096 re. other Tx leaks. I'm hoping this information is
>> useful to openflowplug-dev to find another solution for Bug 9038.
>>
>>
>> Tx,
>>
>> M.
>>
>> PS: Wrote about some blurb about the new tooling which came out of this
>> on http://blog2.vorburger.ch/2017/09/how-to-find-transaction-
>> related-memory.html
>>
>> --
>>
>> Michael Vorburger, Red Hat
>> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
>>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Controller/Clustering Carbon SR2 Blocker Bug

[Abhijit Kumbhare]

Luis,

That is not how the vote went - the TSC voted to drop TSDR from Nitrogen.
Maybe you & others got confused about the options & wrongly voted for them
to be dropped? Please see the vote below:

colindixon: #startvote shall the TSC give TSDR until EOD tomorrow (8/18) to
get patches for autorelease and int/dist or drop them from nitrogen? drop,
abstain, friday
[10:36am] odl_meetbot: Begin voting on: shall the TSC give TSDR until EOD
tomorrow (8/18) to get patches for autorelease and int/dist or drop them
from nitrogen? Valid vote options are drop, abstain, friday.
[10:36am] odl_meetbot: Vote using '#vote OPTION'. Only your last vote
counts.
[10:36am] rovarga: #vote drop
[10:37am] jamoluhrsen: #vote drop
[10:37am] skitt: #vote drop
[10:37am] anipbu: #vote drop
[10:37am] colindixon: #vote abstain
[10:37am] lori: #vote abstain
[10:37am] shague: #vote drop
[10:37am] zxiiro: #drop
[10:37am] edwarnicke: #vote abstain
[10:37am] zxiiro: #vote drop
[10:37am] LuisGomez: #vote drop
[10:37am] vishnoianil: #vote drop
[10:37am] abhijitkumbhare: #vote friday
[10:37am] colindixon: #endvote
[10:37am] odl_meetbot: Voted on "shall the TSC give TSDR until EOD tomorrow
(8/18) to get patches for autorelease and int/dist or drop them from
nitrogen?" Results are
[10:37am] odl_meetbot: abstain (3): colindixon, lori, edwarnicke
[10:37am] odl_meetbot: drop (8): rovarga, skitt, anipbu, LuisGomez, shague,
jamoluhrsen, zxiiro, vishnoianil
[10:37am] odl_meetbot: friday (1): abhijitkumbhare
[10:38am] colindixon: #agreed we will drop TSDR from Nitrogen based on the
TSC assessment of risk in adding them back
[10:38am]

Regards,
Abhijit

On Thu, Aug 17, 2017 at 1:08 PM, Luis Gomez  wrote:

> YuLing,
>
> Today TSC decided to give TSDR until EOD tomorrow (8/18) to get patches
> for autorelease and int/dist. I would suggest to push the patches today if
> you can to avoid last minute surprises.
>
> BR/Luis
>
>
> > On Aug 17, 2017, at 12:47 PM, YuLing Chen 
> wrote:
> >
> > Hi An and Colin,
> >
> > We really would like to get TSDR back to Nitrogen...is there still
> chance for us to do so?
> >
> > As what I mentioned, we've got Karaf upgrade completed and merged. The
> only remaining task is adding it to integration/distribution. We can finish
> it tonight.
> >
> > Would it still be possible for us to catch the Nitrogen train?
> >
> > Thanks,
> >
> > YuLing
> >
> > On Thu, Aug 17, 2017 at 12:26 AM, YuLing Chen 
> wrote:
> > Hi An,
> >
> > Sorry for the delay and this news.
> >
> > Actually, I've just merged TSDR karaf 4 migration, but seems to the
> Oxygen branch.
> >
> > https://git.opendaylight.org/gerrit/#/c/60916/
> >
> >
> > Is it too late to get into Nitrogen?
> >
> > We were about to add TSDR to integration/distribution...should we still
> continue with that effort? In Oxygen or Nitrogen branch?
> >
> > Thanks,
> > YuLing
> >
> > On Wed, Aug 16, 2017 at 4:35 PM, An Ho  wrote:
> > +Add CONTROLLER team.
> >
> > Hi Tom Pantelis and Robert Varga,
> >
> > Please help investigate this issue blocking Carbon SR2.  Several
> projects are having issues with their 3node tests.  We believe
> https://git.opendaylight.org/gerrit/#/c/61433/ is causing problems in
> 3node tests.  Please let us know if we can revert the patch or provide a
> new patch to fix the blocking issue.
> >
> > Best Regards,
> > An Ho
> >
> >
> > -Original Message-
> > From: release-boun...@lists.opendaylight.org [mailto:
> release-boun...@lists.opendaylight.org] On Behalf Of Sam Hague
> > Sent: Wednesday, August 16, 2017 3:55 PM
> > To: Robert Varga; Jamo Luhrsen; Stephen Kitt; Release (
> rele...@lists.opendaylight.org)
> > Subject: Re: [release] https://git.opendaylight.org/gerrit/#/c/61433/
> causing problems in 3node tests
> >
> > forgot to include release list
> >
> > looks like multiple projects are having 3node issues: openflowplugin,
> > netvirt, controller and vtn.
> >
> > On Wed, Aug 16, 2017 at 6:42 PM, Sam Hague  wrote:
> > > Robert,
> > >
> > > the patch seems to be causing issues for the 3node ha tests [1]. Over
> > > half the test fails now ever since that patch went in. Any idea how it
> > > could produce the following exception? This repeats all through the
> > > tests.
> > >
> > > java.lang.IllegalStateException: Store tree
> > > org.opendaylight.yangtools.yang.data.api.schema.tree.spi.
> MaterializedContainerNode@38ce1623
> > > and candidate base
> > > org.opendaylight.yangtools.yang.data.api.schema.tree.spi.
> MaterializedContainerNode@78447ed8
> > > differ.
> > > TransactionCommitFailedException{message=canCommit encountered an
> > > unexpected failure, errorList=[RpcError [message=canCommit encountered
> > > an unexpected failure, severity=ERROR,
> > >
> > >
> > > Thanks, Sam
> > >
> > > [1] https://jenkins.opendaylight.org/releng/view/netvirt-csit/
> job/netvirt-csit-3node-openstack-ocata-upstream-stateful-carbon/93/
> > 

[controller-dev] OpenFlow Plugin dependency on your project

[Abhijit Kumbhare]

Hello OpenFlow Java, controller project & MD-SAL,

This is a request for acknowledgement that OpenFlow Plugin is dependent on
your project - the usual drill :)

Thanks,
Abhijit
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Stepping Down as Controller PTL, PTL Election

[Abhijit Kumbhare]

Congrats Tom! Well deserved!

On Thu, Oct 27, 2016 at 3:42 PM, Tom Pantelis  wrote:

> So that's 3 of 5 committers voting +1, that's a majority. I'm declaring
> victory
>
> On Wed, Oct 26, 2016 at 8:24 AM, Anil Vishnoi 
> wrote:
>
>> +1 for Tom Pantelis Nomination for PTL.
>>
>> On Tue, Oct 25, 2016 at 9:50 AM, Edward Warnicke 
>> wrote:
>>
>>> +1
>>>
>>> On Thu, Oct 13, 2016 at 8:42 AM, Tom Pantelis 
>>> wrote:
>>>
 I'd like to nominate myself.

 Tom

 On Thu, Oct 13, 2016 at 11:35 AM, Anton Tkáčik 
 wrote:

> Hi,
> As you noticed for  I was not able to participate as PTL during last
> months..
> For Carbon this situation will not change, and I will be unable to
> participate as PTL for Controller project, so:
>
> - I am stepping down from role of  Controller PTL
>
> I want to open PTL nominations / election for Controller project lead.
>
> Thanks for understanding,
> Tony Tkacik
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>

 ___
 controller-dev mailing list
 controller-dev@lists.opendaylight.org
 https://lists.opendaylight.org/mailman/listinfo/controller-dev


>>>
>>> ___
>>> controller-dev mailing list
>>> controller-dev@lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>
>>>
>>
>>
>> --
>> Thanks
>> Anil
>>
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [openflowplugin-dev] Regression in OF cluster test

[Abhijit Kumbhare]

Jozef,

Can you also try action #4?

*4. Anil & OPENFLOWPLUGIN team will attempt to reproduce locally in order
to establish if this is a real blocker.  We strongly recommend that the
team enable "debug" on some runs while trying to reproduce the bug.*

*   Deliverable: Comment on bugzilla [2] to confirm if Bug 6658 is a real
blocker.*

Thanks,
Abhijit

On Wed, Sep 7, 2016 at 1:02 PM, An Ho <an...@huawei.com> wrote:

> The CONTROLLER/OPENFLOWPLUGIN team and other folks met to discuss the
> status of this bug and the current plan of action is as follows:
>
>
>
> 1. TomP & CONTROLLER team will remove the invalid test(s) as per Bug 6659
> [1].
>
>Deliverable: Patch(es) removing or fixing the tests.
>
> 2. The release team will schedule a respin of RC3.2 with the VBD fix at
> 9/7 23:59 UTC.
>
>Deliverable: Boron RC3.2 Common Karaf Disitrbution.
>
> 3. Luis & OPENFLOWPLUGIN team will run OFP tests a few more times.
>
>Deliverable: Comment on bugzilla [2] to confirm if we only get the
> expected 26 failures in subsequent runs.
>
> 4. Anil & OPENFLOWPLUGIN team will attempt to reproduce locally in order
> to establish if this is a real blocker.  We strongly recommend that the
> team enable "debug" on some runs while trying to reproduce the bug.
>
>Deliverable: Comment on bugzilla [2] to confirm if Bug 6658 is a real
> blocker.
>
> 5. Luis & OPENFLOWPLUGIN team will fix the tests that are failing because
> of the change in behavior of candidate lists.
>
>Deliverable: Patch(es) fixing tests.
>
>
>
> Best Regards,
>
> An Ho
>
>
>
> [1] https://bugs.opendaylight.org/show_bug.cgi?id=6659
>
> [2] https://bugs.opendaylight.org/show_bug.cgi?id=6658
>
>
>
>
>
> *From:* Colin Dixon [mailto:co...@colindixon.com]
> *Sent:* Wednesday, September 07, 2016 10:35 AM
> *To:* Abhijit Kumbhare
> *Cc:* An Ho; controller-dev; rele...@lists.opendaylight.org;
> openflowplugin-dev
> *Subject:* Re: [openflowplugin-dev] [controller-dev] Regression in OF
> cluster test
>
>
>
> We're trying to figure that out, but if we could have somebody with
> experience in OpenFlow plugin clustering give their 2 cents on if it's a
> bug in the test or the behavior, that would really help.
>
> Thanks,
>
> --Colin
>
>
>
> On Wed, Sep 7, 2016 at 1:33 PM, Abhijit Kumbhare <abhijitk...@gmail.com>
> wrote:
>
> Thanks Luis and An. If it is a test needing update rather than the code -
> it might be better to keep Tom's fix.
>
>
>
> On Wed, Sep 7, 2016 at 10:23 AM, An Ho <an...@huawei.com> wrote:
>
> Still waiting to hear back from the controller team, but in the meantime I
> have created the following blocker bug [1] and updated the tracking
> spreadsheet.
>
>
>
> Hopefully after updating the tests there will not be any issues found.
>
>
>
> Best Regards,
>
> An Ho
>
>
>
> [1] https://bugs.opendaylight.org/show_bug.cgi?id=6658
>
>
>
> *From:* Luis Gomez [mailto:ece...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 10:07 AM
> *To:* An Ho
> *Cc:* controller-dev; openflowplugin-dev; rele...@lists.opendaylight.org;
> Tom Pantelis; Colin Dixon
>
>
> *Subject:* Re: Regression in OF cluster test
>
>
>
> So far I can see it mostly impacts entity-owner API behavior, so updating
> the test cases will fix most of the failures. I am counting 1 day to update
> the test cases and run few times to see if there are other issues. If there
> is no issue after updating the test we can be ready by tomorrow, if there
> are issues after the test update I really doubt we can address them before
> Friday morning.
>
>
>
> BR/Luis
>
>
>
>
>
> On Sep 7, 2016, at 9:59 AM, An Ho <an...@huawei.com> wrote:
>
>
>
> Adding release mailing list since it may impact RC3
>
>
>
> Hi Tom Pantelis,
>
>
>
> Any comments regarding patch 45271.  Seems like it is changed the cluster
> behavior and that introduced regression in OpenFlowPlugin.  Would reverting
> be an option?
>
>
>
> Hi Luis,
>
>
>
> Is the impact confined to only CSIT test cases? Or does it affect end user
> regression of functionality as well?  In other words, would be sufficient
> to update the test cases?  Currently patch 45271 is related to blocker bug
> 6540 so reverting may be difficult.  Hypothetically, if the testing phase
> of RC3.2 will stretch to Friday morning, so would that be enough time to
> update the test cases and rerun the test?
>
>
>
> Best Regards,
>
> An Ho
>
>
>
> [1] https://git.opendaylight.org/gerrit/#/c/45271/
>
> [2] https://bugs.ope