[ 
https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Xu updated HBASE-18226:
---------------------------
    Description: 
Description updated:

In some unusual network environment, forward DNS lookup is supported while 
reverse DNS lookup may not work properly.

This JIRA is to address that HMaster uses the hostname passed from RS instead 
of doing reverse DNS lookup to tells RS which hostname to use during 
reportForDuty() . This has already been implemented by HBASE-12954 by adding 
"useThisHostnameInstead" field in RegionServerStatusProtos.

Currently "useThisHostnameInstead" is optional and RS by default only passes 
port, server start code and server current time info to HMaster during RS 
reportForDuty(). In order to use this field, users currently need to specify 
"hbase.regionserver.hostname" on every regionserver node's hbase-site.xml. This 
causes some trouble in

1. some deployments managed by some management tools like Ambari, which 
maintains the same copy of hbase-site.xml across all the nodes.

2. HBASE-12954 is targeting multihomed hosts, which users want to manually set 
the hostname value for each node. In some cases, I just want RS to use the 
hostname return by the node and set it in useThisHostnameInstead and pass to 
HMaster during reportForDuty().

I would like to introduce a setting that if the setting is set to true, 
"useThisHostnameInstead" will be set to the hostname RS gets from the node. 
Then HMaster will skip reverse DNS lookup because it sees 
"useThisHostnameInstead" field is set in the request.

"hbase.regionserver.report.hostname.to.master", is it a good name?

--------------------
Regarding the hostname returned by the RS node, I read the source code again 
(including hadoop-common dns.java). By default RS gets hostname by calling 
InetAddress.getLocalHost().getCanonicalHostName(). If users specify 
"hbase.regionserver.dns.interface" or "hbase.regionserver.dns.nameserver" or 
some underlying system configuration changes (eg. modifying 
/etc/nsswitch.conf), it may first read from DNS or other sources instead of 
first checking /etc/hosts file.


  was:
Description updated:

In some unusual network environment, forward DNS lookup is supported while 
reverse DNS lookup may not work properly.

This JIRA is to address that HMaster uses the hostname passed from RS instead 
of doing reverse DNS lookup to tells RS which hostname to use during 
reportForDuty() . This has already been implemented by HBASE-12954 by adding 
"useThisHostnameInstead" field in RegionServerStatusProtos.

Currently "useThisHostnameInstead" is optional and RS by default only passes 
port, server start code and server current time info to HMaster during RS 
reportForDuty(). In order to use this field, users currently need to specify 
"hbase.regionserver.hostname" on every regionserver node's hbase-site.xml. This 
causes some trouble in

1. some deployments managed by some management tools like Ambari, which 
maintains the same copy of hbase-site.xml across all the nodes.

2. HBASE-12954 is targeting multihomed hosts, which users want to manually set 
the hostname value for each node. In some cases, I just want RS to use the 
hostname return by the node and set it in useThisHostnameInstead and pass to 
HMaster during reportForDuty().

I would like to introduce a setting that if the setting is set to true, 
"useThisHostnameInstead" will be set to the hostname RS gets from the node. 
Then HMaster will skip reverse DNS lookup because it sees 
"useThisHostnameInstead" field is set in the request.

"hbase.regionserver.report.hostname.to.master", is it a good name?



> Disable reverse DNS lookup at HMaster and use default hostname provided by 
> RegionServer
> ---------------------------------------------------------------------------------------
>
>                 Key: HBASE-18226
>                 URL: https://issues.apache.org/jira/browse/HBASE-18226
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Duo Xu
>         Attachments: HBASE-18226.001.patch, HBASE-18226.002.patch
>
>
> Description updated:
> In some unusual network environment, forward DNS lookup is supported while 
> reverse DNS lookup may not work properly.
> This JIRA is to address that HMaster uses the hostname passed from RS instead 
> of doing reverse DNS lookup to tells RS which hostname to use during 
> reportForDuty() . This has already been implemented by HBASE-12954 by adding 
> "useThisHostnameInstead" field in RegionServerStatusProtos.
> Currently "useThisHostnameInstead" is optional and RS by default only passes 
> port, server start code and server current time info to HMaster during RS 
> reportForDuty(). In order to use this field, users currently need to specify 
> "hbase.regionserver.hostname" on every regionserver node's hbase-site.xml. 
> This causes some trouble in
> 1. some deployments managed by some management tools like Ambari, which 
> maintains the same copy of hbase-site.xml across all the nodes.
> 2. HBASE-12954 is targeting multihomed hosts, which users want to manually 
> set the hostname value for each node. In some cases, I just want RS to use 
> the hostname return by the node and set it in useThisHostnameInstead and pass 
> to HMaster during reportForDuty().
> I would like to introduce a setting that if the setting is set to true, 
> "useThisHostnameInstead" will be set to the hostname RS gets from the node. 
> Then HMaster will skip reverse DNS lookup because it sees 
> "useThisHostnameInstead" field is set in the request.
> "hbase.regionserver.report.hostname.to.master", is it a good name?
> --------------------
> Regarding the hostname returned by the RS node, I read the source code again 
> (including hadoop-common dns.java). By default RS gets hostname by calling 
> InetAddress.getLocalHost().getCanonicalHostName(). If users specify 
> "hbase.regionserver.dns.interface" or "hbase.regionserver.dns.nameserver" or 
> some underlying system configuration changes (eg. modifying 
> /etc/nsswitch.conf), it may first read from DNS or other sources instead of 
> first checking /etc/hosts file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to