Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 84A7A200CB8 for ; Sat, 17 Jun 2017 02:33:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 837C1160BEC; Sat, 17 Jun 2017 00:33:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A697C160BDD for ; Sat, 17 Jun 2017 02:33:04 +0200 (CEST) Received: (qmail 28268 invoked by uid 500); 17 Jun 2017 00:33:03 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 28257 invoked by uid 99); 17 Jun 2017 00:33:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Jun 2017 00:33:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 5B6A1C17D4 for ; Sat, 17 Jun 2017 00:33:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ONd_iu77yGwX for ; Sat, 17 Jun 2017 00:33:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 40B8D5F297 for ; Sat, 17 Jun 2017 00:33:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 69EA1E0A2F for ; Sat, 17 Jun 2017 00:33:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 26FB224001 for ; Sat, 17 Jun 2017 00:33:00 +0000 (UTC) Date: Sat, 17 Jun 2017 00:33:00 +0000 (UTC) From: "Duo Xu (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-18226) Disable reverse DNS lookup at HMaster and use default hostname provided by RegionServer MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sat, 17 Jun 2017 00:33:05 -0000 [ https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Xu updated HBASE-18226: --------------------------- Description: This JIRA is to address the similar problem as HBASE-12954, but there are some little differences, 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so users can configure it on every regionserver with preferred hostnames. However, this configuration cannot be set through Ambari or other configuration management tools because each regionserver has a different value of this setting, which means each node needs a different hbase-site.xml. 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN mappings. In current implementation when regionserver starts, {code} String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead : rpcServices.isa.getHostName(); {code} it uses FQDN names here but on HMaster side, it will do reverse DNS lookup which cannot be resolved. {code} // if regionserver passed hostname to use, // then use it instead of doing a reverse DNS lookup ServerName rs = master.getServerManager().regionServerStartup(request, ia); {code} My proposed fix is to add a new configuration "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver will use the value returned by *rpcServices.isa.getHostName()* as the hostname overwriting whatever users specifies in "*hbase.regionserver.hostname*" and send to HMaster as part of . HMaster will not do reverse DNS lookup, which has been implemented in HBASE-12954. If users want to provide their own hostnames in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be false. I will submit a patch later today. was: This JIRA is to address the similar problem as HBASE-12954, but there are some little differences, 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so users can configure it on every regionserver with preferred hostnames. However, this configuration cannot be set through Ambari or other configuration management tools because each regionserver has a different value of this setting, which means each node needs a different hbase-site.xml. 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN mappings. In current implementation when regionserver starts, {code} String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead : rpcServices.isa.getHostName(); {code} it uses FQDN names here but on HMaster side, it will do reverse DNS lookup which cannot be resolved. {code} // if regionserver passed hostname to use, // then use it instead of doing a reverse DNS lookup ServerName rs = master.getServerManager().regionServerStartup(request, ia); {code} My proposed fix is to add a new configuration "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver will use the value returned by *rpcServices.isa.getHostName()* as the hostname overwriting whatever users specifies in "*hbase.regionserver.hostname*" and send to HMaster. HMaster will not do reverse DNS lookup, which has been implemented in HBASE-12954. If users want to provide their own hostnames in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be false. I will submit a patch later today. > 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 > > > This JIRA is to address the similar problem as HBASE-12954, but there are some little differences, > 1. HBASE-12954 provides the configuration "hbase.regionserver.hostname" so users can configure it on every regionserver with preferred hostnames. However, this configuration cannot be set through Ambari or other configuration management tools because each regionserver has a different value of this setting, which means each node needs a different hbase-site.xml. > 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a FQDN by modifying /etc/hosts on that node. We do not want HMaster to do reverse DNS lookup because HMaster VM's /etc/hosts does not have regionserver VM's FQDN mappings. In current implementation when regionserver starts, > {code} > String hostName = shouldUseThisHostnameInstead() ? useThisHostnameInstead : > rpcServices.isa.getHostName(); > {code} > it uses FQDN names here but on HMaster side, it will do reverse DNS lookup which cannot be resolved. > {code} > // if regionserver passed hostname to use, > // then use it instead of doing a reverse DNS lookup > ServerName rs = master.getServerManager().regionServerStartup(request, ia); > {code} > My proposed fix is to add a new configuration "*hbase.regionserver.hostname.auto*". If it is set to true, then Regionserver will use the value returned by *rpcServices.isa.getHostName()* as the hostname overwriting whatever users specifies in "*hbase.regionserver.hostname*" and send to HMaster as part of . HMaster will not do reverse DNS lookup, which has been implemented in HBASE-12954. If users want to provide their own hostnames in "*hbase.regionserver.hostname*", "*hbase.regionserver.hostname.auto*" must be false. > I will submit a patch later today. -- This message was sent by Atlassian JIRA (v6.4.14#64029)