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. 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)
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. Istvan 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> ------------------------------ ------------------------------