Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Michael Vorburger 
On Mon, Aug 13, 2018 at 5:50 AM Luis Gomez  wrote:

> This will take care of integration and distribution remaining changes for
> neon:
>
> https://git.opendaylight.org/gerrit/#/c/75151/
>

cool, now we just need to get autorelease to actually pass again... ;-) I'm
still, right now, seeing various failures on
https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
from the following projects:

* lispflowmapping
* bgpcep
* netconf
* controller

I'll see if I can help with controller myself ASAP - hoping bgpcep and
lispflowmapping and netconf fix their failures in autorelease...

BR/Luis
>
> On Aug 11, 2018, at 6:07 AM, Robert Varga  wrote:
>
> On 10/08/18 00:05, Michael Vorburger wrote:
>
> On Thu, Aug 9, 2018 at 11:59 PM Michael Vorburger  > wrote:
>
>On Thu, Aug 9, 2018 at 4:55 PM Anil Belur
>mailto:abe...@linuxfoundation.org
> >> wrote:
>
>Hello Everyone,
>
>We have performed branch cutting today with the master branch
>blocked. The work is complete and the master branch (Neon) is
>now open for development again.
>
>Note: A reminder for projects to rebase their existing master
>branch patches to ensure they are building against the post
>version bumped versions of code base.
>
>
>Thank you! But the distribution jobs are still broken
>(e.g.
> https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-neon/2/console
> )
>- is someone looking into and going to fix those? Anil, not
>neccessarily looking at you - I'm guessing integration/distribution
>folks will know what where still needs bumping versions?
>
>
> erm, oups, no wait, hit Send too early - perhaps more importantly than
> distribution failures: at least genius is still completely broken
> currently,
> see
> https://jenkins.opendaylight.org/releng/job/genius-maven-verify-neon-mvn35-openjdk8/1/consoleFull
> ... I'm guessing we did not yet run deploy jobs on all projects (in
> order of the dependency tree) to populate Nexus, yet?
>
>
> Everything is go, bu archetypes need
> https://git.opendaylight.org/gerrit/#/c/75136/ and branching...
>
> archetypes https://git.opendaylight.org/gerrit/#/c/75136/ merged. How
come this project was missed before? Should it be in autorelease? (It
currently is not, according to
https://github.com/opendaylight/releng-autorelease.)

Anil, will you do the branching on archetypes? Does it need to be added
somewhere to not be forgotten next time?


> Regards,
> Robert
>
> ___
> dev mailing list
> d...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/dev
>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Anil Belur 
On Mon, Aug 13, 2018 at 4:38 PM Michael Vorburger 
wrote:

> On Mon, Aug 13, 2018 at 5:50 AM Luis Gomez  wrote:
>
>> This will take care of integration and distribution remaining changes for
>> neon:
>>
>> https://git.opendaylight.org/gerrit/#/c/75151/
>>
>
> cool, now we just need to get autorelease to actually pass again... ;-)
> I'm still, right now, seeing various failures on
> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> from the following projects:
>
> * lispflowmapping
> * bgpcep
> * netconf
> * controller
>
> I'll see if I can help with controller myself ASAP - hoping bgpcep and
> lispflowmapping and netconf fix their failures in autorelease...
>
> BR/Luis
>>
>> On Aug 11, 2018, at 6:07 AM, Robert Varga  wrote:
>>
>> On 10/08/18 00:05, Michael Vorburger wrote:
>>
>> On Thu, Aug 9, 2018 at 11:59 PM Michael Vorburger > > wrote:
>>
>>On Thu, Aug 9, 2018 at 4:55 PM Anil Belur
>>mailto:abe...@linuxfoundation.org
>> >> wrote:
>>
>>Hello Everyone,
>>
>>We have performed branch cutting today with the master branch
>>blocked. The work is complete and the master branch (Neon) is
>>now open for development again.
>>
>>Note: A reminder for projects to rebase their existing master
>>branch patches to ensure they are building against the post
>>version bumped versions of code base.
>>
>>
>>Thank you! But the distribution jobs are still broken
>>(e.g.
>> https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-neon/2/console
>> )
>>- is someone looking into and going to fix those? Anil, not
>>neccessarily looking at you - I'm guessing integration/distribution
>>folks will know what where still needs bumping versions?
>>
>>
>> erm, oups, no wait, hit Send too early - perhaps more importantly than
>> distribution failures: at least genius is still completely broken
>> currently,
>> see
>> https://jenkins.opendaylight.org/releng/job/genius-maven-verify-neon-mvn35-openjdk8/1/consoleFull
>> ... I'm guessing we did not yet run deploy jobs on all projects (in
>> order of the dependency tree) to populate Nexus, yet?
>>
>>
>> Everything is go, bu archetypes need
>> https://git.opendaylight.org/gerrit/#/c/75136/ and branching...
>>
>> archetypes https://git.opendaylight.org/gerrit/#/c/75136/ merged. How
> come this project was missed before? Should it be in autorelease? (It
> currently is not, according to
> https://github.com/opendaylight/releng-autorelease.)
>
> Anil, will you do the branching on archetypes? Does it need to be added
> somewhere to not be forgotten next time?
>

Micheal, Any project which is not a part of AR is presumably a self managed
project, and therefore branch cutting need to be performed be the PTL.
Let me know if archetypes needs to be included in AR, I do remember this
was included in stable/oxygen, but am not aware as to what changed in
between?

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

Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Robert Varga 
On 13/08/18 14:06, Anil Belur wrote:
> 
> https://git.opendaylight.org/gerrit/#/c/75151/
> 
> 
> cool, now we just need to get autorelease to actually pass again... ;-)
> I'm still, right now, seeing various failures
> on 
> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> from the following projects:
> 

00:04:11.596 Entering 'mdsal'
00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate

mdsal is not getting updated to the proper commit, which should be
3346408b80c3dd860d42f18469c7e35aa01cfee3

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Michael Vorburger 
On Mon, Aug 13, 2018 at 2:09 PM Robert Varga  wrote:

> On 13/08/18 14:06, Anil Belur wrote:
> >
> > https://git.opendaylight.org/gerrit/#/c/75151/
> >
> >
> > cool, now we just need to get autorelease to actually pass again... ;-)
> > I'm still, right now, seeing various failures
> > on
> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> > from the following projects:
> >
>
> 00:04:11.596 Entering 'mdsal'
> 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate
>
> mdsal is not getting updated to the proper commit, which should be
> 3346408b80c3dd860d42f18469c7e35aa01cfee3
>

I've hopefully fixed it with https://git.opendaylight.org/gerrit/#/c/75167/

by doing what I've documented on
https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind
(which can perhaps be improved)

but it begs the quesiton why we have to manually do this?
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [opendaylight-dev] [release] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Anil Belur 
On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger 
wrote:

> On Mon, Aug 13, 2018 at 2:09 PM Robert Varga  wrote:
>
>> On 13/08/18 14:06, Anil Belur wrote:
>> >
>> > https://git.opendaylight.org/gerrit/#/c/75151/
>> >
>> >
>> > cool, now we just need to get autorelease to actually pass again... ;-)
>> > I'm still, right now, seeing various failures
>> > on
>> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
>> > from the following projects:
>> >
>>
>> 00:04:11.596 Entering 'mdsal'
>> 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate
>>
>> mdsal is not getting updated to the proper commit, which should be
>> 3346408b80c3dd860d42f18469c7e35aa01cfee3
>>
>
> I've hopefully fixed it with
> https://git.opendaylight.org/gerrit/#/c/75167/
>
> by doing what I've documented on
> https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind
> (which can perhaps be improved)
>
> but it begs the quesiton why we have to manually do this?
>

Robert, Michael: Thank you, I've merged the change #75167 and restarted AR
#6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not
sure about this.

The issue is when we update the submodules recursively AR should get
forwarded to the head on the remote but instead it gets forwarded locally.
Using the `--remote` on the CLI seem to get us the latest changes.

$ git submodule update --init
Submodule path 'mdsal': checked out
'3e5d53eefead8a109f72b9d658432050d01e8cf1'

$ git submodule update --init --remote
Submodule path 'mdsal': checked out
'3346408b80c3dd860d42f18469c7e35aa01cfee3'

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

Re: [controller-dev] [release] [opendaylight-dev] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Thanh Ha 
On Mon, Aug 13, 2018 at 5:59 AM Anil Belur 
wrote:

> On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger 
> wrote:
>
>> On Mon, Aug 13, 2018 at 2:09 PM Robert Varga  wrote:
>>
>>> On 13/08/18 14:06, Anil Belur wrote:
>>> >
>>> > https://git.opendaylight.org/gerrit/#/c/75151/
>>> >
>>> >
>>> > cool, now we just need to get autorelease to actually pass again... ;-)
>>> > I'm still, right now, seeing various failures
>>> > on
>>> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
>>> > from the following projects:
>>> >
>>>
>>> 00:04:11.596 Entering 'mdsal'
>>> 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate
>>>
>>> mdsal is not getting updated to the proper commit, which should be
>>> 3346408b80c3dd860d42f18469c7e35aa01cfee3
>>>
>>
>> I've hopefully fixed it with
>> https://git.opendaylight.org/gerrit/#/c/75167/
>>
>> by doing what I've documented on
>> https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind
>> (which can perhaps be improved)
>>
>> but it begs the quesiton why we have to manually do this?
>>
>
> Robert, Michael: Thank you, I've merged the change #75167 and restarted AR
> #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not
> sure about this.
>
> The issue is when we update the submodules recursively AR should get
> forwarded to the head on the remote but instead it gets forwarded locally.
> Using the `--remote` on the CLI seem to get us the latest changes.
>
> $ git submodule update --init
> Submodule path 'mdsal': checked out
> '3e5d53eefead8a109f72b9d658432050d01e8cf1'
>
> $ git submodule update --init --remote
> Submodule path 'mdsal': checked out
> '3346408b80c3dd860d42f18469c7e35aa01cfee3'
>

It is absolutely critical that when we update .gitmodules and the to update
the submodule reference pointer:

https://git.opendaylight.org/gerrit/75100
https://git.opendaylight.org/gerrit/75019

is merged ASAP. Gerrit will only auto-update submodule subscriptions for a
submodule, if the submodule is on the latest HEAD of branch. If we merged
the submodule update patch after MD-SAL's v2.6.x branch has moved, the HEAD
won't be in sync anymore and Gerrit will not pull in the updates.

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

Re: [controller-dev] [release] [opendaylight-dev] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Anil Belur 
On Mon, Aug 13, 2018 at 6:48 PM Thanh Ha 
wrote:

> On Mon, Aug 13, 2018 at 5:59 AM Anil Belur 
> wrote:
>
>> On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger 
>> wrote:
>>
>>> On Mon, Aug 13, 2018 at 2:09 PM Robert Varga  wrote:
>>>
 On 13/08/18 14:06, Anil Belur wrote:
 >
 > https://git.opendaylight.org/gerrit/#/c/75151/
 >
 >
 > cool, now we just need to get autorelease to actually pass again...
 ;-)
 > I'm still, right now, seeing various failures
 > on
 https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
 > from the following projects:
 >

 00:04:11.596 Entering 'mdsal'
 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate

 mdsal is not getting updated to the proper commit, which should be
 3346408b80c3dd860d42f18469c7e35aa01cfee3

>>>
>>> I've hopefully fixed it with
>>> https://git.opendaylight.org/gerrit/#/c/75167/
>>>
>>> by doing what I've documented on
>>> https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind
>>> (which can perhaps be improved)
>>>
>>> but it begs the quesiton why we have to manually do this?
>>>
>>
>> Robert, Michael: Thank you, I've merged the change #75167 and restarted
>> AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not
>> sure about this.
>>
>> The issue is when we update the submodules recursively AR should get
>> forwarded to the head on the remote but instead it gets forwarded locally.
>> Using the `--remote` on the CLI seem to get us the latest changes.
>>
>> $ git submodule update --init
>> Submodule path 'mdsal': checked out
>> '3e5d53eefead8a109f72b9d658432050d01e8cf1'
>>
>> $ git submodule update --init --remote
>> Submodule path 'mdsal': checked out
>> '3346408b80c3dd860d42f18469c7e35aa01cfee3'
>>
>
> It is absolutely critical that when we update .gitmodules and the to
> update the submodule reference pointer:
>
> https://git.opendaylight.org/gerrit/75100
> https://git.opendaylight.org/gerrit/75019
>
> is merged ASAP. Gerrit will only auto-update submodule subscriptions for a
> submodule, if the submodule is on the latest HEAD of branch. If we merged
> the submodule update patch after MD-SAL's v2.6.x branch has moved, the HEAD
> won't be in sync anymore and Gerrit will not pull in the updates.
>
> Regards,
> Thanh
>

JJB SCM submodule supports a tracking flag, to retrive the tip of the
configured branch always. I think using the flag would avoid potential sync
issues in the future. Any thoughts?

"
tracking (bool) - Retrieve the tip of the configured branch in .gitmodules
(Uses ‘–remote’ option which requires git>=1.8.2)
"
https://docs.openstack.org/infra/jenkins-job-builder/scm.html?highlight=scm


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

Re: [controller-dev] [release] [opendaylight-dev] [OpenDaylight TSC] [releng] Fluorine branch cutting

2018-08-13 Thread Thanh Ha 
On Mon, Aug 13, 2018 at 6:53 AM Anil Belur 
wrote:

> On Mon, Aug 13, 2018 at 6:48 PM Thanh Ha 
> wrote:
>
>> On Mon, Aug 13, 2018 at 5:59 AM Anil Belur 
>> wrote:
>>
>>> On Mon, Aug 13, 2018 at 5:52 PM Michael Vorburger 
>>> wrote:
>>>
 On Mon, Aug 13, 2018 at 2:09 PM Robert Varga  wrote:

> On 13/08/18 14:06, Anil Belur wrote:
> >
> > https://git.opendaylight.org/gerrit/#/c/75151/
> >
> >
> > cool, now we just need to get autorelease to actually pass again...
> ;-)
> > I'm still, right now, seeing various failures
> > on
> https://jenkins.opendaylight.org/releng/job/genius-validate-autorelease-neon/8/console
> > from the following projects:
> >
>
> 00:04:11.596 Entering 'mdsal'
> 00:04:11.607 mdsal 3e5d53eefead8a109f72b9d658432050d01e8cf1 Validate
>
> mdsal is not getting updated to the proper commit, which should be
> 3346408b80c3dd860d42f18469c7e35aa01cfee3
>

 I've hopefully fixed it with
 https://git.opendaylight.org/gerrit/#/c/75167/

 by doing what I've documented on
 https://wiki.opendaylight.org/view/RelEng/Autorelease/Maintenance_Guide#Fix_up_broken_autorelease_which_fell_behind
 (which can perhaps be improved)

 but it begs the quesiton why we have to manually do this?

>>>
>>> Robert, Michael: Thank you, I've merged the change #75167 and restarted
>>> AR #6. The .gitmodules seem to set to the correct branch (v2.6.x), I am not
>>> sure about this.
>>>
>>> The issue is when we update the submodules recursively AR should get
>>> forwarded to the head on the remote but instead it gets forwarded locally.
>>> Using the `--remote` on the CLI seem to get us the latest changes.
>>>
>>> $ git submodule update --init
>>> Submodule path 'mdsal': checked out
>>> '3e5d53eefead8a109f72b9d658432050d01e8cf1'
>>>
>>> $ git submodule update --init --remote
>>> Submodule path 'mdsal': checked out
>>> '3346408b80c3dd860d42f18469c7e35aa01cfee3'
>>>
>>
>> It is absolutely critical that when we update .gitmodules and the to
>> update the submodule reference pointer:
>>
>> https://git.opendaylight.org/gerrit/75100
>> https://git.opendaylight.org/gerrit/75019
>>
>> is merged ASAP. Gerrit will only auto-update submodule subscriptions for
>> a submodule, if the submodule is on the latest HEAD of branch. If we merged
>> the submodule update patch after MD-SAL's v2.6.x branch has moved, the HEAD
>> won't be in sync anymore and Gerrit will not pull in the updates.
>>
>> Regards,
>> Thanh
>>
>
> JJB SCM submodule supports a tracking flag, to retrive the tip of the
> configured branch always. I think using the flag would avoid potential sync
> issues in the future. Any thoughts?
>
> "
> tracking (bool) - Retrieve the tip of the configured branch in .gitmodules
> (Uses ‘–remote’ option which requires git>=1.8.2)
> "
> https://docs.openstack.org/infra/jenkins-job-builder/scm.html?highlight=scm
>
>

This would cause a situation where someone cloning commit 123abc from
autorelease is no longer guaranteed to be building the same commits from
each project. The autorelease job's release flag in autorelease becomes
useless as it no longer reflects the commits that was built for the
particular release.

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

[controller-dev] Circuit breaker problem

2018-08-13 Thread Luis Gomez 
Hi Brian,

Is the problem you talked during TWS today related to this one:

https://jira.opendaylight.org/browse/CONTROLLER-1789 


From the ticket it seems this occurs when there is high number of disk 
transactions and the disk happens to be an slow one (e.g. NFS).

BR/Luis

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

Re: [controller-dev] Circuit breaker problem

2018-08-13 Thread FREEMAN, BRIAN D 
+ Dan wrt ONAP Casablanca

From: Luis Gomez 
Sent: Monday, August 13, 2018 1:46 PM
To: FREEMAN, BRIAN D 
Cc: controller-dev 
Subject: Circuit breaker problem

Hi Brian,

Is the problem you talked during TWS today related to this one:

https://jira.opendaylight.org/browse/CONTROLLER-1789

>From the ticket it seems this occurs when there is high number of disk 
>transactions and the disk happens to be an slow one (e.g. NFS).

BR/Luis

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

Re: [controller-dev] Circuit breaker problem

2018-08-13 Thread Ajay Lele 
Fyi, added some notes to the ticket

On Mon, Aug 13, 2018 at 10:49 AM, FREEMAN, BRIAN D  wrote:

> + Dan wrt ONAP Casablanca
>
>
>
> *From:* Luis Gomez 
> *Sent:* Monday, August 13, 2018 1:46 PM
> *To:* FREEMAN, BRIAN D 
> *Cc:* controller-dev 
> *Subject:* Circuit breaker problem
>
>
>
> Hi Brian,
>
>
>
> Is the problem you talked during TWS today related to this one:
>
>
>
> https://jira.opendaylight.org/browse/CONTROLLER-1789
> 
>
>
>
> From the ticket it seems this occurs when there is high number of disk
> transactions and the disk happens to be an slow one (e.g. NFS).
>
>
>
> BR/Luis
>
>
>
> ___
> 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] controller not up in 2m

2018-08-13 Thread Jamo Luhrsen 

Hi team,

Does anyone know what happened here?

https://paste.fedoraproject.org/paste/ynvKX0LCsFIPMf13AagrQg

I have a local script where I'm killing and restarting an ODL instance
(just loading some controller level features) and polling for 2m to make
sure it's up and repeating. It's in a 3 node cluster.

making sure it's up means a 200 response and cluster SyncStatus == true.

It's not the bug I'm looking to catch, but I wanted to ask about it
just in case it's new and/or know.

Seems that some bundles are not coming up.

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

Re: [controller-dev] controller not up in 2m

2018-08-13 Thread Tom Pantelis 
2018-08-09T06:17:47,637 | INFO  |
opendaylight-cluster-data-shard-dispatcher-45 | Shard
  | 214 - org.opendaylight.controller.sal-clustering-commons -
1.7.3.SNAPSHOT | member-1-shard-default-config (Candidate): Starting new
election term 14

All shards are in Candidate and thus haven't converged. This blocks other
bundles from starting. I assume you're testing the issue where a node
doesn't rejoin on restart - looks like you've hit it.

On Mon, Aug 13, 2018 at 7:49 PM, Jamo Luhrsen  wrote:

> Hi team,
>
> Does anyone know what happened here?
>
> https://paste.fedoraproject.org/paste/ynvKX0LCsFIPMf13AagrQg
>
> I have a local script where I'm killing and restarting an ODL instance
> (just loading some controller level features) and polling for 2m to make
> sure it's up and repeating. It's in a 3 node cluster.
>
> making sure it's up means a 200 response and cluster SyncStatus == true.
>
> It's not the bug I'm looking to catch, but I wanted to ask about it
> just in case it's new and/or know.
>
> Seems that some bundles are not coming up.
>
> Thanks,
> JamO
> ___
> 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] controller not up in 2m

2018-08-13 Thread Tom Pantelis 
On Mon, Aug 13, 2018 at 9:06 PM, Tom Pantelis  wrote:

> 2018-08-09T06:17:47,637 | INFO  | 
> opendaylight-cluster-data-shard-dispatcher-45
> | Shard| 214 - 
> org.opendaylight.controller.sal-clustering-commons
> - 1.7.3.SNAPSHOT | member-1-shard-default-config (Candidate): Starting new
> election term 14
>
> All shards are in Candidate and thus haven't converged. This blocks other
> bundles from starting. I assume you're testing the issue where a node
> doesn't rejoin on restart - looks like you've hit it.
>

It joined itself:

2018-08-09T06:16:08,228 | INFO  |
opendaylight-cluster-data-akka.actor.default-dispatcher-51 |
Cluster(akka://opendaylight-cluster-data) | 48 - com.typesafe.akka.slf4j -
2.5.11 | Cluster Node [akka.tcp://opendaylight-cluster-data@172.28.5.1:2550]
- Node [akka.tcp://opendaylight-cluster-data@172.28.5.1:2550] is JOINING,
roles [member-1, dc-default]
2018-08-09T06:16:08,236 | INFO  |
opendaylight-cluster-data-akka.actor.default-dispatcher-51 |
Cluster(akka://opendaylight-cluster-data) | 48 - com.typesafe.akka.slf4j -
2.5.11 | Cluster Node [akka.tcp://opendaylight-cluster-data@172.28.5.1:2550]
- Leader is moving node [akka.tcp://
opendaylight-cluster-data@172.28.5.1:2550] to [Up]


>
> On Mon, Aug 13, 2018 at 7:49 PM, Jamo Luhrsen  wrote:
>
>> Hi team,
>>
>> Does anyone know what happened here?
>>
>> https://paste.fedoraproject.org/paste/ynvKX0LCsFIPMf13AagrQg
>>
>> I have a local script where I'm killing and restarting an ODL instance
>> (just loading some controller level features) and polling for 2m to make
>> sure it's up and repeating. It's in a 3 node cluster.
>>
>> making sure it's up means a 200 response and cluster SyncStatus == true.
>>
>> It's not the bug I'm looking to catch, but I wanted to ask about it
>> just in case it's new and/or know.
>>
>> Seems that some bundles are not coming up.
>>
>> Thanks,
>> JamO
>> ___
>> 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