Description of problem: If the peer happens to be probed on an ip address (instead of hostname), volume creation fails. To identify a friend, glusterd does a strcmp(hostname, peername). Since peername happens to be an ip address here (since we probed an ip-address instead of hostname), glusterd cannot identify hostname as friend (though it is one). Backtrace: Breakpoint 5, glusterd_friend_find_by_hostname (hoststr=0x7f03d8000eb0 "rhs-hpc-srv2", peerinfo=0x927128) at ../../../../../xlators/mgmt/glusterd/src/glusterd-utils.c:4589 4589 if (!strncasecmp (entry->hostname, host, (gdb) p entry->hostname $8 = 0x6fa300 "192.168.1.14" (gdb) l 4584 1024, NULL, 0, 0); 4585 if (ret) 4586 goto out; 4587 4588 list_for_each_entry (entry, &priv->peers, uuid_list) { 4589 if (!strncasecmp (entry->hostname, host, 4590 1024) || !strncasecmp (entry->hostname,hname, 4591 1024)) { 4592 gf_log (this->name, GF_LOG_DEBUG, 4593 "Friend %s found.. state: %d", (gdb) p entry->hostname $9 = 0x6fa300 "192.168.1.14" (gdb) p hname $10 = "rhs-hpc-srv2.lab.eng.blr.redhat.com", '\000' <repeats 988 times> Version-Release number of selected component (if applicable): master How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Ideally glusterd should be doing comparisions on ip-addresses instead of hostname. A rough algorithm would be, 1. getaddrinfo (hostname). 2. compare the list of addresses hostname resolves into with list of friends. The comparision should be done on ip-addresses, not on hostname.
Even following test fails: 1. probe a peer using hostname. 2. Create a volume using one of the ip-addresses of peer (instead of hostname). The failed test case in first comment was: 1. probe a peer using ip-address. 2. Create a volume using hostname. regards, Raghavendra.
[root@rhs-hpc-srv2 ~]# gluster volume create ptop 192.168.1.15:/home/export/ptop Host 192.168.1.15 not a friend [root@rhs-hpc-srv2 ~]# gluster peer status Number of Peers: 1 Hostname: rhs-hpc-srv3 Port: 24007 Uuid: 4b814585-e1cf-42b7-9c47-f9f613ebad7d State: Accepted peer request (Connected) [root@rhs-hpc-srv2 ~]# gluster volume create ptop 10.70.36.23:/home/export/ptop Host 10.70.36.23 not a friend [root@rhs-hpc-srv2 ~]# gluster peer probe 10.70.36.23 Probe on host 10.70.36.23 port 24007 already in peer list [root@rhs-hpc-srv2 ~]# gluster volume create ptop 192.168.1.15:/home/export/ptop Host 192.168.1.15 not a friend [root@rhs-hpc-srv2 ~]# gluster peer probe 192.168.1.15 Probe on host 192.168.1.15 port 24007 already in peer list As can be seen above, though hostname is identified as a friend, none of the ip-addresses the hostname is resolved into are considered as peers.
This seems like the wrong kind of direction to go, to determine if Gluster already knows the other box. Doesn't Gluster have a "host id" UUID type of thing that could be used instead? (not sure of its actual name) JoeJulian pointed out that this seems very related to BZ # 765437 as well.
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice. If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.