Hello everyone, I'd like to kickoff a discuss thread on dev@ to see what folks think about merging the feature branch for HBASE-18095 <https://issues.apache.org/jira/browse/HBASE-18095> into the master. For those of you who aren't following this work, over the last few months, a lot of effort went into a feature branch <https://github.com/apache/hbase/tree/HBASE-18095/client-locate-meta-no-zookeeper> to remove the ZK dependency in the client.
*Please refer to the design doc <https://docs.google.com/document/d/1JAJdM7eUxg5b417f0xWS4NztKCx1f2b6wZrudPtiXF4/edit> attached to the parent jira and go through the subtasks for all the technical details and design considerations*. *TL;DR*: With this feature, the client connection implementation *does not* need access to zookeeper to fetch the connection metadata. Instead, a predefined set of master end points in the configuration are used by clients to fetch the required metadata. This new feature is *enabled by default on the feature branch* and passes the entire nightly test suite (modulo some known flakes not specific to the branch). At this point, I'm not aware of any performance concerns / feature gaps compared to original default implementation. The original registry implementation is still retained and can be used by setting the following client configuration. This kill switch gives the users more flexibility since they have a fallback incase they run into any issues. <property> <!-- Reverts to the original ZK based connection registry implementation --> <name>hbase.client.registry.impl</name> <value>org.apache.hadoop.hbase.client.ZKConnectionRegistry</value> </property> This work is also slated to go into the upcoming releases* 2.3.0* and *1.6.0*. However, it will be *disabled by default*. Having this work back ported to those branches enables users to try it out in their environments and report any feedback. Please speak up (respond to this email) if there are any objections to merging this work in the master branch. Many thanks to Nick Dimiduk, Andrew Purtell and Michael Stack for their invaluable feedback throughout this work. - Bharath
