k.faseela do you want to assign this to yourself, add some logging, and follow up with jluhrsen, or were you hoping I would? 
jluhrsen : Do you hit the issue in a script, or when you run this manually? Self-address is derived from an akka based configuration, wondering whether your script is executing showSvcStatus CLI too early, before this is exposed. And I am wondering whether DNS is not configured properly on your system, that it results in the error.
Else, if you are running this manually giving enough time, could you please give me the output of :
http://<ODL-IP>:8181/jolokia/read/akka:type=Cluster
ok, so I have learned more about this one. 
INFRAUTILS-37 and this are not the same root cause.
TL;DR the /etc/hosts file matters, and stuff internally with odl/jmx/etc will choke if the $(hostname) is not there.
This issue is something that used to show up for me in the karaf console log and I could never figure out what
was wrong, but did not try very hard as it didn't seem to bother anything I was doing. I don't have the old error
I'd see on the console, but it was jmx related and errors connecting to 127.0.0.1
So, the fix for me is to have a proper /etc/hosts file. It was this:
127.0.0.1 localhost localhost.localdomain jamo-rc701.rdocloud ::1 localhost localhost.localdomain jamo-rc701.rdocloud
but, after changing it to this:
127.0.0.1 localhost localhost.localdomain ::1 localhost localhost.localdomain
it works.
This begs the question of what is going on under the hood, because the error says that it's a connection
refused to 127.0.0.1, because I am able to open a connection to 127.0.0.1 on port 6886 which is the
relevant port here. see below with 6886 working and 6887 being refused like we'd expect:
$ nc 127.0.0.1 6886 ^C ]$ nc 127.0.0.1 6887 Ncat: Connection refused.
I can't think of how this matters yet, but we can chalk this up to a user configuration issue, but
that was pretty lame to hunt down.
Jamo, JMX RMI uses InetAddress.getHostByName() inside, and if /etc/hosts does not have the hostname, it does not work.
But, what is still not clear to me is, why we go via JMX RMI for 127.0.0.1 which is local address.
Output of this will help me to analyse that further : http://<ODL-IP>:8181/jolokia/read/akka:type=Cluster
$ curl -u "admin:admin" http://localhost:8181/jolokia/read/akka:type=Cluster | python -m json.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 651 0 651 0 0 83482 0 --:--:-- --:--:-- --:--:-- 93000 { "request": { "mbean": "akka:type=Cluster", "type": "read" }, "status": 200, "timestamp": 1525358717, "value": { "Available": true, "ClusterStatus": "{\n \"members\": [\n {\n \"address\": \"akka.tcp://opendaylight-cluster-data@127.0.0.1:2550\",\n \"roles\": [\n \"dc-default\",\n \"member-1\"\n ],\n \"status\": \"Up\"\n }\n ],\n \"self-address\": \"akka.tcp://opendaylight-cluster-data@127.0.0.1:2550\",\n \"unreachable\": []\n}\n", "Leader": "akka.tcp://opendaylight-cluster-data@127.0.0.1:2550", "MemberStatus": "Up", "Members": "akka.tcp://opendaylight-cluster-data@127.0.0.1:2550", "Singleton": true, "Unreachable": "" } }
So, what are you looking for in that output?
in this output, if self-address matches the ip in the cluster-members, we do localStatusSummary(). I was wondering why the exception you have given shows that RemoteStatusSummary() failed for 127.0.0.1.
Could you please confirm if you are using a build which has this fix?
https://git.opendaylight.org/gerrit/#/c/70842/
I think it was, but it was from 4/17, which is when that patch was merged. Anyway,
below is the same request on a distro built today. looks like the same output:
$ curl -u "admin:admin" http://localhost:8181/jolokia/read/akka:type=Cluster | python -m json.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 651 0 651 0 0 5482 0 --:--:-- --:--:-- --:--:-- 5516 { "request": { "mbean": "akka:type=Cluster", "type": "read" }, "status": 200, "timestamp": 1525458172, "value": { "Available": true, "ClusterStatus": "\{\n \"members\": [\n {\n \"address\": \"akka.tcp://opendaylight-cluster-data@127.0.0.1:2550\",\n \"roles\": [\n \"dc-default\",\n \"member-1\"\n ],\n \"status\": \"Up\"\n }\n ],\n \"self-address\": \"akka.tcp://opendaylight-cluster-data@127.0.0.1:2550\",\n \"unreachable\": []\n}\n", "Leader": "akka.tcp://opendaylight-cluster-data@127.0.0.1:2550", "MemberStatus": "Up", "Members": "akka.tcp://opendaylight-cluster-data@127.0.0.1:2550", "Singleton": true, "Unreachable": "" } }
k.faseela, anything more I can do here? I don't think this is probably a high priority/severity bug, but just making sure the
ball is not in my court 
jluhrsen only thing is whether you had the patch I mentioned above while testing? If it is there the error would not have come even if your /etc/hosts is not proper for single node . Anyways should we close the bug saying it is a missing config?
k.faseela, no I confirmed that I had the patch and gave the output in my last comment. Do you want me to try again?
Yes, I made sathwiksai to try this out locally, and we always see that for 127.0.0.1 it fetches the local status and never go via RMI. In fact that was the main reason why the above patch was pushed. Yesterday, even Vishal tried this out, and we did not see the error. Probably we should try removing hostname from /etc/hosts and see if it works? Will try that out and update.
I tried this locally, removing the hostname in etc/hosts and it worked. I have seen the same before this patch (https://git.opendaylight.org/gerrit/#/c/70842/) pushed. that's the main reason the patch was pushed.
just for kicks I double checked with and without a good /etc/hosts file and I don't see the high level symptoms with those
exceptions. closing this as resolved and verified.