Bug 832941

Summary:	hostname resolve fails on remote peer on 'peer probe' command
Product:	[Community] GlusterFS	Reporter:	fous <honza801>
Component:	cli	Assignee:	Kaushal <kaushal>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	gluster-bugs
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-19 13:33:20 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:
Embargoed:

Description fous 2012-06-18 08:57:29 UTC

Description of problem:
hostname resolve fails on remote peer on 'peer probe' command

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

Steps to Reproduce:
1. thishost> peer probe thathost
2. thathost> peer status
  
Actual results:
Number of Peers: 1

Hostname: <thishost-ipv6-address>
Uuid: bc04bbf1-aa45-4566-9206-9587bc09ff4d
State: Peer in Cluster (Connected)

Expected results:
Number of Peers: 1

Hostname: thishost
Uuid: bc04bbf1-aa45-4566-9206-9587bc09ff4d
State: Peer in Cluster (Connected)


Additional info:
hi,

there are 2 machines running glusterd, both of them on ipv6 network.
we are trying to make them frieds via 'peer probe' command like this:

1. thishost> peer probe thathost
Probe successful

2. thishost> peer status
Number of Peers: 1

Hostname: thathost
Uuid: 09ba44f6-af65-4216-9504-d4454661aa76
State: Peer in Cluster (Connected)

3. thathost> peer status
Actual results:
Number of Peers: 1

Hostname: <thishost-ipv6-address>
Uuid: bc04bbf1-aa45-4566-9206-9587bc09ff4d
State: Peer in Cluster (Connected)

both machines have ipv6 aaaa and ptr records

after deleting /var/lib/glusterfs/* and 'peer probe' is run from the thathost, everything is OK on thathost. But thishost shows 'Hostname: <thathost-ipv6-address>'

it seems, that the host, we are trying to connect to, is not able to resolve the hostname of the initiator.

thanks for hints

Comment 1 Kaushal 2012-06-18 11:44:31 UTC

After probing 'thathost' from 'thishost', do "gluster peer probe 'thishost'" on 'thathost'. This command should output somesthing saying "'thishost' is already a part of the cluster", but it should update peer status to now use the hostname of 'thishost' instead of it ipv6 address.

Comment 2 fous 2012-06-18 13:18:10 UTC

hi,

your solution works, also restarting glusterd works, but it is a dirty workaround. let's assume i have 10 peers, it is really uncomfortable to run the command on all of them for each other peer. (btw this is 10x9 = 90 commands !)

please fix the problem, this should be definitely a bug.

thanks
fous

Comment 3 Kaushal 2012-06-19 06:53:23 UTC

Hi fous,

You have made a wrong assumption. 10 peers don't require 90 commands to be executed, just 10. 9 probe commands from peer1 to the other peers and 1 reverse probe from any one of the 9 peers to peer1. glusterd handles the syncing of the hostname across the peers. For N peers only N commands need to be issued so that the cluster is in sync wrt to hostnames of peers.
Also, AFAIK restarting glusterd doesn't update the IP's to hostnames.

If you still feel that this is uncomfortable, leave this open. Else, please close it.

Kaushal

Comment 4 fous 2012-06-19 13:33:20 UTC

hi,

thanks for all the details. i find this still little bit uncomfortable, but good enough.

thanks for all of your replies
marking closed
fous