[
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)