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.
Confirmed. One peer in a pair has the cname while the other has the raw ip.
Adding myself to the me too list. I'm willing to test a patch that shows up in git. Mike Robbert
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)
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.
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.
(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.
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.
(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
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 ~]#
PATCH: http://patches.gluster.com/patch/5679 in master (mgmt/glusterd: "peer probe new-hostname" should replace old-hostname of friend)
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
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.