Description
Scope
This issue involves the following topics:
- ensuring that HBase is reachable externally via listener endpoints (see parent issue)
- ensure that these endpoints (or a load balancer that uses them) is consistently used in the UI screens
- ensure the HBase advertises the nodes it is running on so that e.g. an accurate locality can be derived (see feat: HBase resolvable endpoints docker-images#1159)
UI endpoint resolution - previous notes
UI endpoint resolution
The endpoints exposed in the HBase UI (mainly the master) are not resolvable for end-users. This means that, while it is possible to use the listener classes to write discovery information to ConfigMaps (so that users can easily reach master/regionserver/rest-server UIs), links referenced in these webpages - most obviously the list of region servers - are dead.
Context
- Hbase uses the following internally for hostname and port resolution. If these settings are not in hbase-site.xml then a default mechanism is used.
hbase.{ master | regionserver| rest }.{ hostname | port }
- the default mechanism involves a DNS lookup (see here and here), which also requires that reverse DNS lookups not be disabled. See here.
- the endpoint information written to Zookeeper is what is used for listing the regionservers, and is also used for internal binding
- this causes problems as HBase does not have access to the host network
- tweaking internal details for the sake of user-facing endpoints runs the risk of breaking things, so a safer solution would be to patch HBase to use listener information only for the purpose of providing externally-reachable endpoints
Proposed solution
- extend proto structs and use where needed - see below Use Node-IPs for external reachability and localities #641 (comment)
Node advertisement
- the aim is to use the proto struct extensions when calculating localities etc. Not yet researched.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
In Progress