Re: [controller-dev] [integration-dev] CSIT test bugs

2017-04-20 Thread Jozef Bacigál
Luis can you send me the karaf logs you made with DEBUG ?


Jozef


Od: Luis Gomez 
Odoslané: štvrtok, 20. apríla 2017 3:01:56
Komu: Miroslav Macko; controller-dev
Kópia: Jozef Bacigál; openflowplugin-dev; integration-...@lists.opendaylight.org
Predmet: Re: [integration-dev] CSIT test bugs

CC-ing controller-dev anyway,

These messages shown in one of the candidates (.101) after OF device owner 
(.103) is killed. RPC "add-flow" to the candidate (.101) which is not the new 
owner will fail until we see the message *Leader can perform its duties again* 
below after few mins.

This behavior is not observed in Boron where RPC works very quickly after OF 
device owner is killed.

Current bug: https://bugs.opendaylight.org/show_bug.cgi?id=8185

BR/Luis


On Apr 19, 2017, at 5:28 PM, Luis Gomez 
mailto:ece...@gmail.com>> wrote:

I activated DEBUG for openflow and again I do not see anything conclusive, 
however I observed following cluster logging in the candidate instance I send 
the RPC and fails:

2017-04-19 23:45:48,003 | INFO  | ult-dispatcher-4 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:46:27,990 | INFO  | ult-dispatcher-6 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:47:28,000 | INFO  | ult-dispatcher-3 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:48:28,000 | INFO  | ult-dispatcher-3 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:48:31,999 | INFO  | lt-dispatcher-17 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can perform its duties again

Also the RPC seems to work after the last line which is at least 3 mins after 
the owner goes down. Any idea what is going on or should we involve cluster 
people here?

BR/Luis



On Apr 18, 2017, at 11:59 PM, Miroslav Macko 
mailto:miroslav.ma...@pantheon.tech>> wrote:

Luis it would be great, if you can try with DEBUG on 
org.opendaylight.openflowplugin.impl.

Thanks a lot,
Miro

Od: Luis Gomez mailto:ece...@gmail.com>>
Odoslané: streda, 19. apríla 2017 5:57:35
Kom

Re: [controller-dev] Re-configuration of module using Blueprint on Karaf4 distribution

2017-04-20 Thread Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
Hi Tom,
Sorry for late answer but I had some troubles with building karaf4 
distributions since there were some changes of karaf version in parents.
Right now I’m testing my karaf4 migration changes on Carbon branch and 
everything (including re-configuration via restconf) works well.
Maybe it has been fixed in the meantime.
I’ll continue with the migration and will test it also on Nitrogen and I let 
you know if I’ll hit the issue again.

Thank you very much for your help.
Tomas
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, April 19, 2017 4:41 PM
To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
Cc: controller-dev@lists.opendaylight.org; John Burns (johnburn)
Subject: Re: [controller-dev] Re-configuration of module using Blueprint on 
Karaf4 distribution

Ok - so you're using the . The code that handles that is 
in org.opendaylight.controller.blueprint.ext.DataStoreAppConfigMetadata. 
Basically it registers a DTCL for changes to the yang model. On change, it 
restarts the blueprint container. Enable debug and see if it's getting 
triggered.

Tom

On Wed, Apr 19, 2017 at 10:08 AM, Tomas Janciga -X (tjanciga - PANTHEON 
TECHNOLOGIES at Cisco) mailto:tjanc...@cisco.com>> wrote:
No, I’m referring to re-configuration of blueprint modules via restconf.
First re-configuration passes and all next attempts are resulting with 200OK 
but the new configuration is not used by the module.

Thanks,
Tomas
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, April 19, 2017 4:02 PM
To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
Cc: 
controller-dev@lists.opendaylight.org;
 John Burns (johnburn)

Subject: Re: [controller-dev] Re-configuration of module using Blueprint on 
Karaf4 distribution

Are you referring to re-configuration of a config subsystem (CSS) module via 
restconf? If so, I don't know why it doesn't seem to work but I would suggest 
not using this mechanism as it's problematic for upgrades. I suggest to also 
convert to blueprint as, since Boron, we have been moving away from the CSS. In 
fact, we just discussed on the kernel call about officially deprecating it in 
Nitrogen with eventual removal in the future.

Tom

On Wed, Apr 19, 2017 at 7:41 AM, Tomas Janciga -X (tjanciga - PANTHEON 
TECHNOLOGIES at Cisco) mailto:tjanc...@cisco.com>> wrote:
Thanks for clarification Tom.
Now I understand that the stack trace is probably not related to the problem 
with re-configuration of modules on Karaf4.

But is the issue with re-configuration already known please ?
I’ve tried to find some project using karaf4-parent and using Blueprint 
configuration of modules, but I haven’t found any.
Is IoTDM project the first project testing it ?

Thanks,
Tomas
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Tuesday, April 18, 2017 4:12 PM
To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
Cc: 
controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Re-configuration of module using Blueprint on 
Karaf4 distribution

Tomas,

The "Unable to create a proxy object..." message is related to blueprint and is 
benign (logged as INFO). When registering a service instance, it tries to 
create a proxy for it (for the quiesce functionality which isn't important) - 
on failure it uses the original instance (lucky for us). This happens sometimes 
- not sure why - it's an issue in the Aries Proxy lib. It would be nice if it 
used the JDK proxy APIs for interfaces as that's robust and only used the ASM 
stuff when proxying a concrete class as the JDK proxy API doesn't support that. 
OSGi services normally advertise an interface anyway (best practice).

Tom

On Tue, Apr 18, 2017 at 9:55 AM, Tomas Janciga -X (tjanciga - PANTHEON 
TECHNOLOGIES at Cisco) mailto:tjanc...@cisco.com>> wrote:
Hi guys,
I’m working on migration of IoTDM project to Karaf4.
I’ve done some draft changes of onem2m-core module and it’s submodules. Some of 
the submodules are using Blueprint configuration.
I have a problem when I’m running Karaf4 distribution and I try to re-configure 
some of these modules through RESTCONF.
First time everything works and module is re-configured successfully but second 
time (and for all next attempts as well) I just receive 200OK but the changed 
configuration is not used (the module is not re-loaded using the new 
configuration).
I’ve noticed a stack trace in logs, it’s attached. It’s printed during the 
first re-configuration (nothing is printed during second and all next attempts 
to re-configure the module).

Could you let me know please, if it is some known issue or whether it works 
well in general and the issue is related to my changes only ?
The same steps works well for Karaf3 distribution of IoTDM.
Thanks
Tomas

opendaylight-user@root>log:display
2017-04-18 06:38:51,010 | INFO  | erRest

[controller-dev] Cohert not getting triggered for augmented nodes

2017-04-20 Thread Satish Dutt
Hi Tomas,

I am writing a Cohert trying to validate a subtree data, which is augmented to 
a target node in the same module. For registering the cohert, I am creating an 
instance of the same and also the DomDataTreeIdentifier by using the 
YangInstanceIdentifier instance having the sub-tree path. Registration does not 
throw any exception, but the canCommit() of my cohert is not triggered whenever 
I push the JSON data to the sub-tree. I have put below the yang and the code 
snippets. Is the way of registering the subtree for the the Cohert validations 
wrong in my case ? Please advise.

container controller {
}

module connector-config {
...
...

container controller {
}

/*
* Augumented -> controllerconfig management model
*/
augment "/controller" {
ext:augment-identifier ControllerMgmtAugmentation;
container controller-common-mgmt {
config true;
list tenant {
key id;
leaf id {
type string;
description "ID of tenant";
mandatory true;
}

Description "Tenant details";
uses controller-common-group;
 }
}
}
...
...
}

@Override
public synchronized Future> registerCommitCohort() {
...
...
  final YangInstanceIdentifier connectorConfigPath = 
YangInstanceIdentifier.builder(

YangInstanceIdentifier.of(Controller.QNAME)).node(ControllerCommonMgmt.QNAME).
node(Tenant.QNAME).node(Tenant.QNAME).build();


commitCohortReg.set(commitCohortRegistry.registerCommitCohort(
new org.opendaylight.mdsal.dom.api.DOMDataTreeIdentifier(

org.opendaylight.mdsal.common.api.LogicalDatastoreType.CONFIGURATION,
connectorConfigPath), new 
ConnectorDataTreeCommitCohort(domDataBroker, dataProvider)));

return RpcResultBuilder.success().buildFuture();
}

Regards,
-Satish

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


Re: [controller-dev] [integration-dev] CSIT test bugs

2017-04-20 Thread Luis Gomez
I added cluster logs to the bug.

> On Apr 20, 2017, at 12:00 AM, Jozef Bacigál  
> wrote:
> 
> Luis can you send me the karaf logs you made with DEBUG ?
> 
> Jozef
> Od: Luis Gomez mailto:ece...@gmail.com>>
> Odoslané: štvrtok, 20. apríla 2017 3:01:56
> Komu: Miroslav Macko; controller-dev
> Kópia: Jozef Bacigál; openflowplugin-dev; 
> integration-...@lists.opendaylight.org 
> 
> Predmet: Re: [integration-dev] CSIT test bugs
>  
> CC-ing controller-dev anyway,
> 
> These messages shown in one of the candidates (.101) after OF device owner 
> (.103) is killed. RPC "add-flow" to the candidate (.101) which is not the new 
> owner will fail until we see the message *Leader can perform its duties 
> again* below after few mins.
> 
> This behavior is not observed in Boron where RPC works very quickly after OF 
> device owner is killed.
> 
> Current bug: https://bugs.opendaylight.org/show_bug.cgi?id=8185 
> 
> 
> BR/Luis
> 
> 
>> On Apr 19, 2017, at 5:28 PM, Luis Gomez > > wrote:
>> 
>> I activated DEBUG for openflow and again I do not see anything conclusive, 
>> however I observed following cluster logging in the candidate instance I 
>> send the RPC and fails:
>> 
>> 2017-04-19 23:45:48,003 | INFO  | ult-dispatcher-4 | 
>> kka://opendaylight-cluster-data ) | 179 - 
>> com.typesafe.akka.slf4j - 2.4.17 | Cluster Node 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>> ] - Leader can 
>> currently not perform its duties, reachability status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (4)], member status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 
>>  Up seen=false]
>> 
>> 2017-04-19 23:46:27,990 | INFO  | ult-dispatcher-6 | 
>> kka://opendaylight-cluster-data ) | 179 - 
>> com.typesafe.akka.slf4j - 2.4.17 | Cluster Node 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>> ] - Leader can 
>> currently not perform its duties, reachability status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (4)], member status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 
>>  Up seen=false]
>> 
>> 2017-04-19 23:47:28,000 | INFO  | ult-dispatcher-3 | 
>> kka://opendaylight-cluster-data ) | 179 - 
>> com.typesafe.akka.slf4j - 2.4.17 | Cluster Node 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>> ] - Leader can 
>> currently not perform its duties, reachability status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (4)], member status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 
>>  Up seen=false]
>> 
>> 2017-04-19 23:48:28,000 | INFO  | ult-dispatcher-3 | 
>> kka://opendaylight-cluster-data ) | 179 - 
>> com.typesafe.akka.slf4j - 2.4.17 | Cluster Node 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>> ] - Leader can 
>> currently not perform its duties, reachability status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  -> 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: 
>>  Unreachable 
>> [Unreachable] (4)], member status: 
>> [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 
>>  Up seen=true, 
>> akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 
>>  Up seen=false]
>> 
>> 2017-04-19 23:48:31,999 | INFO  | lt-dispatcher-17 | 
>> kka://opendaylight-cluster-data ) | 179 - 
>> com.typesafe.akka.slf4j - 2.4.17 | Cluste

[controller-dev] build failure when 'mvn archetype:generate' using '-DarchetypeCatalog'

2017-04-20 Thread Sam
Hi all,

I'm running coretutorials of ODL according
https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Main

In 'Part 1 - Build with a simple 'Example' module', I run command exactly
as document said as bellow:

mvn archetype:generate -DarchetypeGroupId=org.opendaylight.controller
> -DarchetypeArtifactId=opendaylight-startup-archetype \
> -DarchetypeRepository=
> http://nexus.opendaylight.org/content/repositories/opendaylight.release/ \
> -DarchetypeCatalog=
> http://nexus.opendaylight.org/content/repositories/opendaylight.release/archetype-catalog.xml
> \
> -DarchetypeVersion=1.2.0-Boron


But I got failure:

[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate
> (default-cli) on project standalone-pom: archetypeCatalog '
> http://nexus.opendaylight.org/content/repositories/opendaylight.release/archetype-catalog.xml'
> is not supported anymore. Please read the plugin documentation for details.
> -> [Help 1]



Some one said to remove '-DarchetypeCatalog', but the result remove
'-DarchetypeCatalog' is:

pom.xml
> src
> tests


Which is not as expact:

api/
artifacts/
features/
impl/
karaf/
pom.xml


So how to deal with this?
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [controller-dev] build failure when 'mvn archetype:generate' using '-DarchetypeCatalog'

2017-04-20 Thread Sam
Add  coretutorials-...@lists.opendaylight.org


2017-04-21 10:39 GMT+08:00 Sam :

> Hi all,
>
> I'm running coretutorials of ODL according https://wiki.opendaylight.org/
> view/Controller_Core_Functionality_Tutorials:Main
>
> In 'Part 1 - Build with a simple 'Example' module', I run command exactly
> as document said as bellow:
>
> mvn archetype:generate -DarchetypeGroupId=org.opendaylight.controller
>> -DarchetypeArtifactId=opendaylight-startup-archetype \
>> -DarchetypeRepository=http://nexus.opendaylight.org/content/repositories/
>> opendaylight.release/ \
>> -DarchetypeCatalog=http://nexus.opendaylight.org/content/repositories/
>> opendaylight.release/archetype-catalog.xml \
>> -DarchetypeVersion=1.2.0-Boron
>
>
> But I got failure:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:
>> maven-archetype-plugin:3.0.1:generate (default-cli) on project
>> standalone-pom: archetypeCatalog 'http://nexus.opendaylight.
>> org/content/repositories/opendaylight.release/archetype-catalog.xml' is
>> not supported anymore. Please read the plugin documentation for details. ->
>> [Help 1]
>
>
>
> Some one said to remove '-DarchetypeCatalog', but the result remove
> '-DarchetypeCatalog' is:
>
> pom.xml
>> src
>> tests
>
>
> Which is not as expact:
>
> api/
> artifacts/
> features/
> impl/
> karaf/
> pom.xml
>
>
> So how to deal with this?
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Re: [controller-dev] [integration-dev] CSIT test bugs

2017-04-20 Thread Jozef Bacigál
thanks


Od: Luis Gomez 
Odoslané: piatok, 21. apríla 2017 2:12:12
Komu: Jozef Bacigál
Kópia: Miroslav Macko; controller-dev; openflowplugin-dev; 
integration-...@lists.opendaylight.org
Predmet: Re: [integration-dev] CSIT test bugs

I added cluster logs to the bug.

On Apr 20, 2017, at 12:00 AM, Jozef Bacigál 
mailto:jozef.baci...@pantheon.tech>> wrote:

Luis can you send me the karaf logs you made with DEBUG ?

Jozef

Od: Luis Gomez mailto:ece...@gmail.com>>
Odoslané: štvrtok, 20. apríla 2017 3:01:56
Komu: Miroslav Macko; controller-dev
Kópia: Jozef Bacigál; openflowplugin-dev; 
integration-...@lists.opendaylight.org
Predmet: Re: [integration-dev] CSIT test bugs

CC-ing controller-dev anyway,

These messages shown in one of the candidates (.101) after OF device owner 
(.103) is killed. RPC "add-flow" to the candidate (.101) which is not the new 
owner will fail until we see the message *Leader can perform its duties again* 
below after few mins.

This behavior is not observed in Boron where RPC works very quickly after OF 
device owner is killed.

Current bug: https://bugs.opendaylight.org/show_bug.cgi?id=8185

BR/Luis


On Apr 19, 2017, at 5:28 PM, Luis Gomez 
mailto:ece...@gmail.com>> wrote:

I activated DEBUG for openflow and again I do not see anything conclusive, 
however I observed following cluster logging in the candidate instance I send 
the RPC and fails:

2017-04-19 23:45:48,003 | INFO  | ult-dispatcher-4 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:46:27,990 | INFO  | ult-dispatcher-6 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:47:28,000 | INFO  | ult-dispatcher-3 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:48:28,000 | INFO  | ult-dispatcher-3 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can currently not perform its duties, reachability status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (1), akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 -> 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550: Unreachable 
[Unreachable] (4)], member status: 
[akka.tcp://opendaylight-cluster-data@192.168.0.101:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.102:2550 Up seen=true, 
akka.tcp://opendaylight-cluster-data@192.168.0.103:2550 Up seen=false]

2017-04-19 23:48:31,999 | INFO  | lt-dispatcher-17 | 
kka://opendaylight-cluster-data) | 179 - com.typesafe.akka.slf4j - 2.4.17 | 
Cluster Node [akka.tcp://opendaylight-cluster-data@192.168.0.101:2550] - Leader 
can perform its duties again

Also the RPC seems to work after the last li