I'm +1 for merge to master with it default enabled and to branch-2 with it off by default.
Nice work Bharath. S On Tue, Feb 4, 2020 at 8:37 AM Bharath Vissapragada <bhara...@apache.org> wrote: > 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 >
