Bug 890502

Summary: glusterd fails to identify peer while creating a new volume
Product: [Community] GlusterFS Reporter: Raghavendra G <rgowdapp>
Component: glusterdAssignee: krishnan parthasarathi <kparthas>
Status: CLOSED EOL QA Contact: SATHEESARAN <sasundar>
Severity: unspecified Docs Contact:
Priority: medium    
Version: mainlineCC: bugs, gluster-bugs, kaushal, kwade, nsathyan, rwheeler, shmohan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 902216 (view as bug list) Environment:
Last Closed: 2015-10-22 15:46:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 902216    

Description Raghavendra G 2012-12-27 10:57:01 UTC
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).


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 ""
(gdb) l
4584                                       1024, NULL, 0, 0);
4585                    if (ret)
4586                            goto out;
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 ""
(gdb) p hname
$10 = "rhs-hpc-srv2.lab.eng.blr.redhat.com", '\000' <repeats 988 times>

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
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.

Comment 1 Raghavendra G 2013-03-01 05:44:39 UTC
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.


Comment 2 Raghavendra G 2013-03-01 05:50:03 UTC
[root@rhs-hpc-srv2 ~]# gluster volume create ptop
Host 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
Host not a friend

[root@rhs-hpc-srv2 ~]# gluster peer probe
Probe on host port 24007 already in peer list

[root@rhs-hpc-srv2 ~]# gluster volume create ptop
Host not a friend

[root@rhs-hpc-srv2 ~]# gluster peer probe
Probe on host 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.

Comment 3 Justin Clift 2013-04-09 19:52:37 UTC
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.

Comment 4 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
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.