Bug 890502 - glusterd fails to identify peer while creating a new volume
glusterd fails to identify peer while creating a new volume
Status: CLOSED EOL
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
mainline
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: krishnan parthasarathi
SATHEESARAN
:
Depends On:
Blocks: 902216
  Show dependency treegraph
 
Reported: 2012-12-27 05:57 EST by Raghavendra G
Modified: 2015-11-03 18:06 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 902216 (view as bug list)
Environment:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Raghavendra G 2012-12-27 05:57:01 EST
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.
Comment 1 Raghavendra G 2013-03-01 00:44:39 EST
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.
Comment 2 Raghavendra G 2013-03-01 00:50:03 EST
[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.
Comment 3 Justin Clift 2013-04-09 15:52:37 EDT
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 11:46:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.