Bug 832941 - hostname resolve fails on remote peer on 'peer probe' command
hostname resolve fails on remote peer on 'peer probe' command
Status: CLOSED WONTFIX
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
3.3.0
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kaushal
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 04:57 EDT by fous
Modified: 2012-06-19 09:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-19 09:33:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description fous 2012-06-18 04:57:29 EDT
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 07:44:31 EDT
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 09:18:10 EDT
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 02:53:23 EDT
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 09:33:20 EDT
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

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