+1 from me as well
> On Feb 4, 2020, at 9:33 AM, Nick Dimiduk <[email protected]> wrote: > > Thanks for the summary, and all your efforts on this enhancement, Bharath. > > Let me highlight here on point re: this architecture. Because the Master is > use in place of ZooKeeper for clients to find their way around the cluster, > this changes our operational requirements on the Master. With this feature > enabled, operators will need to keep at least one Master up and responding > to RPC's in order for clients to locate meta. As with the existing ZK-based > meta location discovery, the location is cached by the client so as to not > make excessive calls. There are tests in place that ensure this > functionality behaves appropriately even if Master leader election somehow > fails. > > As for me, I'm +1 on merging this implementation to master and branch-2. > > Thanks, > Nick > >> On Tue, Feb 4, 2020 at 8:37 AM Bharath Vissapragada <[email protected]> >> 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 >>
