[ 
https://issues.apache.org/jira/browse/HBASE-23804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034278#comment-17034278
 ] 

Clay B. commented on HBASE-23804:
---------------------------------

[~ndimiduk] For testing I'm a bit at a loss without functional black-box 
testing and asserting we've bound to the correct port and advertised the 
expected hostname.

However, on a machine with only an external interface and a localhost 
interface, I can see four states we can test:
# Start with no explicit configuration
** Ensure we:
**# advertise the non-localhost hostname
**# bind to both interfaces
** Can verify what we advertised to by connecting to the port, calling 
{{netstat}}, or use something like [Sigar's Java/native 
implementation|https://github.com/hyperic/sigar/blob/master/bindings/java/src/org/hyperic/sigar/cmd/Netstat.java].
 Sadly this isn't a great test as we used to pick an arbitrary non-localhost 
interface before HBASE-12954 on start.
# Start with hostname set to the localhost hostname
** Ensure we only:
**# advertise the localhostname
**# bind to localhost
** Can verify what we advertised to by connecting to the port, calling 
{{netstat}}, or use something like [Sigar's Java/native 
implementation|https://github.com/hyperic/sigar/blob/master/bindings/java/src/org/hyperic/sigar/cmd/Netstat.java].
# Start with hostname set to the external hostname
** Ensure we only:
**# advertise the localhostname
**# bind to localhost
** Can verify what we advertised to by connecting to the port, calling 
{{netstat}}, or use something like [Sigar's Java/native 
implementation|https://github.com/hyperic/sigar/blob/master/bindings/java/src/org/hyperic/sigar/cmd/Netstat.java].
# Start with a hostname which is defined in {{/etc/hosts}} but is not an IP 
interface on the machine
** This is a bit of undefined behavior right now. What I see running this patch 
is that we start, binding to all interfaces and advertising the provided 
hostname in Zookeeper. Interestingly on my single machine pseudo-distributed my 
RS can talk to the master but the master does advertise as the hostname which 
does not exist on the localmachine.
** Again we could, in a mini-cluster test, verify that the hostname and bound 
sockets are matching what was provided; this "multiple personalities" may still 
be useful in a Kubernetes environment where the containers are actually behind 
a service mesh however.

I can not figure out how to test having multiple non-localhost interfaces 
without using a Docker functional test or very fine grained unit-tests though.

> Fix default master addr hostname in master registry
> ---------------------------------------------------
>
>                 Key: HBASE-23804
>                 URL: https://issues.apache.org/jira/browse/HBASE-23804
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 3.0.0, 2.3.0, 1.6.0, HBASE-18095
>            Reporter: Bharath Vissapragada
>            Assignee: Bharath Vissapragada
>            Priority: Major
>             Fix For: HBASE-18095
>
>
> Currently, master RPC server (*not* info server) always binds to the address 
> endpoint to which the default hostname of the server resolves to. However, 
> master registry picks the default end point to connect to as 
> "localhost:16000" when "hbase.masters" are not configured. This is leading to 
> a mismatch because the server may not be listening on the loopback address. 
> This is a problem only in the scripts (single proc/pseudo distributed modes) 
> because these are the cases in which "hbase.masters" is not populated by 
> default.
> The fix is to pick the service endpoint the same way the RPC server does it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to