Bug 763727 - (GLUSTER-1995) Gluster Peer probe command keeps ip address instead of server name in the destination server
Gluster Peer probe command keeps ip address instead of server name in the des...
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
3.1.0
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Pranith Kumar K
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-21 03:35 EDT by Timothy Asir
Modified: 2015-12-01 11:45 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: DNR
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Timothy Asir 2010-10-21 03:35:53 EDT
When we execute peer probe command in one server, the destination server always keeps the ip address instead of server name. This will create a problem when we change the (source) server ip.
Comment 1 Alon 2010-10-21 14:05:56 EDT
Confirmed.  One peer in a pair has the cname while the other has the raw ip.
Comment 2 Michael "Murph" Robbert 2010-10-29 08:56:32 EDT
Adding myself to the me too list. I'm willing to test a patch that shows up in git.

Mike Robbert
Comment 3 Joe Julian 2010-10-29 13:22:26 EDT
This happens regardless of whether dns or hosts file provides host names.

host names and reverse lookups do resolve using hosts command.

To duplicate:
server1# gluster peer probe server2
server1# gluster peer status
Number of Peers: 1

Hostname: server2
Uuid: 83556206-157e-44c5-9f6f-eaabd576bd2b
State: Peer in Cluster (Connected)

server2# gluster peer status
Number of Peers: 1

Hostname: 10.0.0.119
Uuid: 8c180c85-84b5-4cab-9bb3-9bac9f4936ce
State: Peer in Cluster (Connected)
Comment 4 Joe Julian 2010-11-01 21:57:55 EDT
I'm not sure if this directly relates, or if it's a separate bug, but if I change the hostname in the peers to server1 and server2, start glusterd, then try to create a volume using server1 and server2, the cli will report that the local server isn't a friend.

If I set the domain name, however, like server1.domain.dom and server2.domain.dom like "host 10.0.0.119" returns, the cli can successfully create a volume by also using the fqdn names.
Comment 5 Pranith Kumar K 2010-11-02 01:01:06 EDT
seems like bug 763587. Could you try if the same happens with 
http://ftp.gluster.com/pub/gluster/glusterfs/qa-releases/glusterfs-3.1.1qa1.tar.gz

Thanks
Pranith.
Comment 6 Joe Julian 2010-11-02 01:05:41 EDT
(In reply to comment #5)
> seems like bug 763587. Could you try if the same happens with 
> http://ftp.gluster.com/pub/gluster/glusterfs/qa-releases/glusterfs-3.1.1qa1.tar.gz
> 

tried with qa3 and current git (as of commit de001e8659d78dd16ba8515228c70fd2986e56df) with the same results.
Comment 7 Michael "Murph" Robbert 2010-11-02 08:26:52 EDT
Pranith,
This is not Bug 1855. I filed bug 763587 and tested that it was fixed in 3.1.1qa1 and that is when I noticed this problem and was referred to this bug.

Mike

(In reply to comment #5)
> seems like bug 763587. Could you try if the same happens with 
> http://ftp.gluster.com/pub/gluster/glusterfs/qa-releases/glusterfs-3.1.1qa1.tar.gz
> 
> Thanks
> Pranith.
Comment 8 Pranith Kumar K 2010-11-02 09:53:00 EDT
(In reply to comment #4)
> I'm not sure if this directly relates, or if it's a separate bug, but if I
> change the hostname in the peers to server1 and server2, start glusterd, then
> try to create a volume using server1 and server2, the cli will report that the
> local server isn't a friend.
> 
> If I set the domain name, however, like server1.domain.dom and
> server2.domain.dom like "host 10.0.0.119" returns, the cli can successfully
> create a volume by also using the fqdn names.

Could you please add the exact steps you are doing to reproduce the bug.

Pranith
Comment 9 Joey 2010-11-08 15:17:21 EST
Here are the exact steps which recreated the bug:




[root@vm-container-0-0 ~]# service glusterd status
glusterd (pid 3770) is running...
[root@vm-container-0-0 ~]# hostname
vm-container-0-0.local
[root@vm-container-0-0 ~]# host vm-container-0-0.local
vm-container-0-0.local has address 10.19.127.254
[root@vm-container-0-0 ~]# host 10.19.127.254
254.127.19.10.in-addr.arpa domain name pointer vm-container-0-0.local.
[root@vm-container-0-0 ~]# gluster peer probe vm-container-0-1.local
Probe successful
[root@vm-container-0-0 ~]# gluster peer probe vm-container-0-2.local
Probe successful
[root@vm-container-0-0 ~]# gluster peer probe vm-container-0-3.local
Probe successful
[root@vm-container-0-0 ~]# gluster peer probe vm-container-0-4.local
Probe successful
[root@vm-container-0-0 ~]# gluster peer probe vm-container-0-5.local
Probe successful
[root@vm-container-0-0 ~]# gluster peer status
Number of Peers: 5

Hostname: vm-container-0-1.local
Uuid: d60ec177-7434-4201-a97b-296da398bfc0
State: Peer in Cluster (Connected)

Hostname: vm-container-0-2.local
Uuid: 50c6de03-f477-40b7-bc5e-3fd9bd3fe13c
State: Peer in Cluster (Connected)

Hostname: vm-container-0-3.local
Uuid: 920b1f66-0c31-4518-8c0e-a22cc7f25372
State: Peer in Cluster (Connected)

Hostname: vm-container-0-4.local
Uuid: b05fada1-7795-4f9e-901b-8a2890f9587b
State: Peer in Cluster (Connected)

Hostname: vm-container-0-5.local
Uuid: fcf89e37-e1ae-48f6-9511-97272c13c934
State: Peer in Cluster (Connected)

Logging into one of the nodes and checking, the host where the configuration commands were run, I see vm-container-0-0 come back as an IP:


-------------------------------------

[root@vm-container-0-1 ~]# gluster peer status
Number of Peers: 5

Hostname: 10.19.127.254
Uuid: 0ecd3293-3862-4950-98bf-d4cb687893d8
State: Peer in Cluster (Connected)

Hostname: vm-container-0-2.local
Uuid: 50c6de03-f477-40b7-bc5e-3fd9bd3fe13c
State: Peer in Cluster (Connected)

Hostname: vm-container-0-3.local
Uuid: 920b1f66-0c31-4518-8c0e-a22cc7f25372
State: Peer in Cluster (Connected)

Hostname: vm-container-0-4.local
Uuid: b05fada1-7795-4f9e-901b-8a2890f9587b
State: Peer in Cluster (Connected)

Hostname: vm-container-0-5.local
Uuid: fcf89e37-e1ae-48f6-9511-97272c13c934
State: Peer in Cluster (Connected)
[root@vm-container-0-1 ~]#

[root@vm-container-0-1 ~]# host vm-container-0-0.local
vm-container-0-0.local has address 10.19.127.254
[root@vm-container-0-1 ~]# host 10.19.127.254
254.127.19.10.in-addr.arpa domain name pointer vm-container-0-0.local.
[root@vm-container-0-1 ~]#
Comment 10 Anand Avati 2010-11-13 07:02:54 EST
PATCH: http://patches.gluster.com/patch/5679 in master (mgmt/glusterd: "peer probe new-hostname" should replace old-hostname of friend)
Comment 11 Pranith Kumar K 2010-11-13 21:11:11 EST
Every time a probe happens the destination machine should be able to do gethostname() and make sure the source machine's name is resovlable from DNS. The problem is that gethostname() api is a blocking api, if we call this api the main thread in glusterd will be blocked until it responds, so it may timeout to some of the critical events. So we decided to provide a way for the users to change the hostname of the peer using the cli of that machine. If the same machine is probed using different hostname that can be resolved from DNS, all the peers will change the hostname of the peer.

Example: Lets say there are 4 machines in the cluster probed from machine server1, to server2-4. 

The peer status outputs on each will be:

On server1 (Lets say the ip is 192.168.1.179):
hostname: server2
......
hostname: server3
......
hostname: server4

On Server2:
hostname: 192.168.1.179
.......
hostname: server3
......
hostname: server4
......

On server3:
hostname: 192.168.1.179
........
hostname: server2
........
hostname: server4

On server4:
hostname: 192.168.1.179
.....
hostname: server2
......
hostname: server3
......

Now the user can change 192.168.1.179 to server1 by executing the command "peer probe server1" on any of server2-4
Comment 12 Divya 2011-04-13 02:25:51 EDT
The following information is added in Creating Trusted Storage Pools section: After peer probe, in the remote machine, the peer machine information is stored with IP address instead of hostname.

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