Description of problem:

rpc_transport_inet_options_build() in rpc_transport.c always sets address-family option to "inet". client_fill_address_family() uses this option to set sockaddr->sa_family field. Finally gf_resolve_ip6() uses sa_family as a hint to getaddrinfo().

So getaddrinfo() is always called with AF_INET hint, no matter the host address. If the host (peer, for example) has only IPv6 address then getaddrinfo call (and the connection) fails. 

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

glusterfs-server-3.11.2-1.fc26.x86_64

How reproducible:

You do not need to actually have IPv6 addresses assigned to network interfaces. Option transport.address-family inet6 is ignored in this case so it does not matter if the option is set or not.

Steps to Reproduce:

- Select one Gluster node, there is no need to touch other nodes.
 
- Create some /etc/hosts record that has only IPv6 address. For example,
fe80::d37d:fb59:f7fe:63ae peer1

- Stop glusterd. 

- Select one peer and make a backup of correspondent /var/lib/glusterd/peers/ file.

- Modify the peer file so hostname1=peer1

- Start glusterd

- Observe /var/log/glusterfs/glusterd.log

- Do not forget to restore the peer file.

Actual results:

/var/log/glusterfs/glusterd.log has records

[2017-08-08 21:44:54.267498] E [MSGID: 101075] [common-utils.c:300:gf_resolve_ip6] 0-resolver: getaddrinfo failed (Name or service not known)

[2017-08-08 21:44:54.267554] E [name.c:267:af_inet_client_get_remote_sockaddr] 0-management: DNS resolution failed on host peer1

Expected results:

glusterd shall resolve the peer1 name and continue the connection attempt (that will, probably, fail as the IPv6 address does not exist).

Additional info:

I would suggest adding new option to glusterd.vol that controls outgoing address-family with default value "inet". The option shall have possible values "inet", "inet6", and "unspecified" (or "inet6,inet"). For example,

option transport.outgoing.address-family inet6

The option shall be used in rpc_transport_inet_options_build(). client_fill_address_family() shall be adjusted to allow "unspecified" value.

This way existing Gluster configuration will continue to work the same way. 

BTW The error message "DNS resolution failed" is misleading, it shall be "name/address resolution failed". Also there is related message

[options.c:954:xl_opt_validate] 0-management: option 'address-family' is deprecated, preferred is 'transport.address-family', continuing with correction

as rpc_transport_inet_options_build() sets the deprecated option name.