[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306275#comment-14306275
]
stack commented on HBASE-12954:
-------------------------------
Going back to the patch after the above back and forth:
The addition to RegionServerStatus should not be hostname, it should be
useThisHostnameInstead of something like that.
And same for all other cases of 'hostname' in this patch.
Should probably just pass in the whole request object rather piecemeal it
adding new param:
305 ServerName rs = master.serverManager.regionServerStartup(
306 request.hasHostname() ? null : ia, request.getHostname(),
request.getPort(),
306 request.getServerStartCode(), request.getServerCurrentTime());
307 request.getServerStartCode(), request.getServerCurrentTime());
Passing a null for the inetaddress when we want to force use of the RS hostname
is plain cryptic. The logic for whether to use the RS hostname is spread about
rather than encapsulated inside regionServerStartup. Not even a comment.
On RS, why keep hostname as a datamember? Don't we have ServerName? Maybe its
to check if we are in the special state where RS name has been specified.
Would be better to add a method that we'd call that says whether this condition
is in effect rather than do this cryptic test of hostname == null in a few
places about the code.
Why special-casing check of ServeName the master returns us? If we specified
hostname to use, ain't the master going to send us back the hostname we
specified? If you were throwing exception or aborting because master was not,
the check would be worth it but its just being logged which is of no use.
Needs a test that shows we don't list regionservers twice; once by the way the
master sees the regionserver and then a second time by this dictated hostname.
> Ability impaired using HBase on multihomed hosts
> ------------------------------------------------
>
> Key: HBASE-12954
> URL: https://issues.apache.org/jira/browse/HBASE-12954
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.4
> Reporter: Clay B.
> Assignee: Ted Yu
> Priority: Minor
> Attachments: 12954-v1.txt, Hadoop Three Interfaces.png
>
>
> For HBase clusters running on unusual networks (such as NAT'd cloud
> environments or physical machines with multiple IP's per network interface)
> it would be ideal to have a way to both specify:
> # which IP interface to which HBase master or region-server will bind
> # what hostname HBase will advertise in Zookeeper both for a master or
> region-server process
> While efforts such as HBASE-8640 go a long way to normalize these two sources
> of information, it is not possible in the current design of the properties
> available to an administrator for these to be unambiguously specified.
> One has been able to request {{hbase.master.ipc.address}} or
> {{hbase.regionserver.ipc.address}} but one can not specify the desired HBase
> {{hbase.master.hostname}}. (It was removed in HBASE-1357, further I am
> unaware of a region-server equivalent.)
> I use a configuration management system to generate all of my configuration
> files on a per-machine basis. As such, an option to generate a file
> specifying exactly which hostname to use would be helpful.
> Today, specifying the bind address for HBase works and one can use an
> HBase-only DNS for faking what to put in Zookeeper but this is far from
> ideal. Network interfaces have no intrinsic IP address, nor hostname.
> Specifing a DNS server is awkward as the DNS server may differ from the
> system's resolver and is a single IP address. Similarly, on hosts which use a
> transient VIP (e.g. through keepalived) for other services, it means there's
> a seemingly non-deterministic hostname choice made by HBase depending on the
> state of the VIP at daemon start-up time.
> I will attach two networking examples I use which become very difficult to
> manage under the current properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
