On Fri, 1 Mar 2024 at 07:47, Istvan Toth <st...@cloudera.com.invalid> wrote:
> That's a pretty fundamental change, and would break a lot of use cases and > applications that hard-code the assumption of the ZK registry. To the best of my knowledge, the znode structure in ZooKeeper has never been a part of our public API. I have no sympathy for systems that assume its presence. Making a breaking change like removing the previous default connection > method in a minor version also feels wrong. > (It may go against the compatibility policy, though I haven't checked) This is a fair argument. I think it would be better to deprecate it in 3.0 and remove it in 4.0, or > at least deprecate it in 2.6 and remove it in 4.0. > This is how the HBase 2.x API changes were handled, where the removal of > the old HBase 1.x APIs were targeted to 3.0. > The ZK registry code is small, and doesn't cost much to keep in the > codebase. And in fact, I now realize that something like it will continue to exist even after the class is removed from our public API because I suspect that the HMaster will need to use it in order to bootstrap itself. Still, it could be moved into hbase-server and kept as an internal concern. So then, should we not deprecate it at all? We let the RPC implementation flip over as default in 3.0, but the ZK implementation sticks around into perpetuity? As far as I know, we have no plan to move off of ZooKeeper entirely ; etcd and RAFT are still just talk, right? If there’s nothing to motivate its complete removal, I guess there no reason to deprecate it. Thanks, Nick On Fri, Mar 1, 2024 at 12:15 AM Andrew Purtell <apurt...@apache.org> wrote: > > > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0. > > > > > > > > > > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk <ndimi...@apache.org> > wrote: > > > > > Heya, > > > > > > We have long had the ambition to get away from ZooKeeper as the means > by > > > which a client interfaces with an HBase cluster. The ConnectionRegistry > > was > > > introduced in 2.0 as part of the asynchronous client implementation > [0], > > > then called the ClusterRegistry. The name changed and a new > > implementation > > > backed by an HMaster endpoint was introduced, called the > > > MasterConnectionRegistry. That implementation was made more generic as > > the > > > RpcConnectionRegistry, which can be backed by HMaster or RegionServer > > > processes. Finally, many of the teething issues [1] with the > > > RpcConnectionRegistry have been worked out. As of now, > > > RpcConnectionRegistry is the default path for client cluster access on > > > branch-3 [2]. > > > > > > With 2.6 upon us, we'd like to formalize the deprecation cycle for > client > > > implementations connecting to a cluster using the ZKConnectionRegistry. > > > > > > I have been using the RpcConnectionRegistry in several deployments > since > > > the 2.4 release line. In a deployment without using secured > connections, > > > it's a drop-in replacement. For secured deployments, it's simpler, > > because > > > clients don't need to be granted ZooKeeper connection credentials. > > Movement > > > of RPC burden from the ZooKeeper cluster to Region Servers is really > nice > > > for spreading out the load. > > > > > > Maybe others have deployed the feature as well and have some experience > > to > > > report back? > > > > > > Based on my experience, I am in favor of marking ZKConnectionRegistry > as > > > Deprecated starting in 2.6 with a plan to remove it in 3.1 ... or 3.2 > if > > > necessary. > > > > > > What do you say? Any objections? > > > > > > Thanks, > > > Nick > > > > > > [0]: https://issues.apache.org/jira/browse/HBASE-15921 > > > [1]: https://issues.apache.org/jira/browse/HBASE-26149 > > > [2]: https://issues.apache.org/jira/browse/HBASE-26174 > > > > > > > > > -- > > Best regards, > > Andrew > > > > Unrest, ignorance distilled, nihilistic imbeciles - > > It's what we’ve earned > > Welcome, apocalypse, what’s taken you so long? > > Bring us the fitting end that we’ve been counting on > > - A23, Welcome, Apocalypse > > > > > -- > *István Tóth* | Sr. Staff Software Engineer > *Email*: st...@cloudera.com > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > ------------------------------ >
