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 A52A3200CB8 for ; Sat, 17 Jun 2017 02:26:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A4249160BDD; Sat, 17 Jun 2017 00:26:08 +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 DD3BD160BF1 for ; Sat, 17 Jun 2017 02:26:07 +0200 (CEST) Received: (qmail 20457 invoked by uid 500); 17 Jun 2017 00:26:07 -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 20440 invoked by uid 99); 17 Jun 2017 00:26:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Jun 2017 00:26:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 9159BC07B3 for ; Sat, 17 Jun 2017 00:26:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.211 X-Spam-Level: X-Spam-Status: No, score=-99.211 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id E8CfButimfTh for ; Sat, 17 Jun 2017 00:26:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 899065F4A7 for ; Sat, 17 Jun 2017 00:26:05 +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 51522E0DBC for ; Sat, 17 Jun 2017 00:26:03 +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 7F84F24009 for ; Sat, 17 Jun 2017 00:26:01 +0000 (UTC) Date: Sat, 17 Jun 2017 00:26:01 +0000 (UTC) From: "Duo Xu (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (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:26:08 -0000 [ https://issues.apache.org/jira/browse/HBASE-18226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052574#comment-16052574 ] Duo Xu commented on HBASE-18226: -------------------------------- [~esteban] Sorry for the confusion. Let me explain more clearly. 1. HBASE-12954 provided a configuration called "hbase.regionserver.hostname" so users can use whatever hostname they preferred for each regionserver/node. That means each regionserver/node needs a different copy of hbase-site.xml. Because the value of "hbase.regionserver.hostname" is different for different nodes. Ambari or any other configuration management tool does not support to set different values of a setting on different nodes. Thus HBASE-12954 introduced configuration does not work with any configuration management tool. 2. This JIRA intends to let RS uses the value returned by getHostName() rather than users specify it and send it as part of RegionServerStartupRequest to HMaster, so HMaster will use this hostname instead of doing reverse DNS lookup as some cloud environment does not provide reverse DNS lookup for the VMs. This part has been implemented in HBASE-12954. 3. In Azure HDInsight clusters cloud setup, we want to give each regionserver node a FQDN by modifying /etc/hosts on that node. In my testing, without modifying /etc/hosts (our current setting), getHostName() will return IP of the VM, after adding the FQDN entry, it returns the FQDN. However, since each VM's host file only contains itself FQDN entry, reverse DNS lookup won't work on HMaster side to get the RS FQDN. This is the issue we want to resolve, we do not want HMaster to do reverse DNS lookup. So comparing with HBASE-12954, the goal is slightly different HBASE-12954 provides users options to give whatever hostname they want to each regionserver and disable reverse DNS lookup on HMaster side. Configuration management tools will not support this configuration because each node needs a different value. This JIRA provides users options to use the value returned by getHostName(), which is the current default option in HBase, to HMaster and disable reverse DNS lookup on HMaster side (without this patch, it will do reverse DNS lookup). Configuration management tools will support this configuration because it is a true/false value, users do not need to explicitly set the hostname for each node. > 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 because each regionserver has a different value of this setting. > 2. In Azure HDInsight clusters, we want to give each RegionServer/workernode a FQDN by modifying /etc/hosts on that node, then 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. -- This message was sent by Atlassian JIRA (v6.4.14#64029)