Description of problem:
=======================

With a fresh setup, setting the volume option "nfs.rpc-auth-allow" or "nfs.rpc-auth-reject" with hostname is behaving erratically.

The behavior in my observation was as follows:

1. nfs.rpc-auth-allow "hostname" : rejects the client in the hostname from mounting via nfs.

2. nfs.rpc-auth.reject "hostname" : allows the client in the hostname to mount via nfs.

3. After enabling nfs.addr-namelookup (off by default):
    nfs.rpc-auth-allow "hostname" : allows the client in the hostname to mount via nfs.
    nfs.rpc-auth-reject "hostname" : rejects the client in the hostname from mounting via nfs.

4. After resetting nfs.addr-namelookup (off by default):
    behavior is the same as in #3 whereas it should be same as #1 and #2

5. A restart of nfs server on all nodes also yields the same outcome as #4


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

glusterfs-3.12.2-8.el7rhgs.x86_64


How reproducible:
=================

Always


Steps to Reproduce:
===================

1. Set the volume option "nfs.rpc-auth-allow" and/or "nfs.rpc-auth-reject" with the hostname
2. Try mounting the volume on the client whose hostname is provided in the auth options
3. Set the nfs.addr-namelookup option to "on"
4. Repeat step 2
5. Reset the nfs.addr-namelookup option
6. Repeat step 1


Actual results:
===============

As explained in the description.


Expected results:
=================

With the nfs.addr-namelookup option off, nfs auth options do not work as intended. But with nfs.addr-namelookup option on, nfs auth options should work as expected. Although nfs.addr-namelookup option was set "on", after resetting that option, the nfs auth options should go back to not work as intended.


Additional info:
================

Providing a hostname which is different than what is used after setting the option nfs.addr-namelookup "on" and then resetting it also seems to resolve the new hostname.