Deprecation does not mean disabling, it does not even mean changing the default.
On Thu, Feb 29, 2024 at 10:49 PM 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. > 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> > ------------------------------ > ------------------------------ > -- 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
