On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth <st...@cloudera.com.invalid> wrote:
> I checked our compatibility promise just now: > https://hbase.apache.org/book.html#hbase.versioning > > If we consider the way we use properties to define the cluster connection a > part of the client API > (and I personally do) then we cannot remove the ZK registry > functionality before 4.0, even > if it is deprecated in 2.6. > This makes sense -- thanks for keeping me honest, Istvan. So then, with no current plan to make HBase run without ZooKeeper, there's really no need to deprecate the ZKConnectionRegistry. A ZooKeeper quorum connection string will continue to be a supported part of our supported client-facing interface until we have a reason to discard it? I'm fine with this decision. If that's the consensus, we can close HBASE-23324 as Won't Fix. Let's see if any other voices join the thread. On Fri, Mar 1, 2024 at 10:12 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > > > For 3.0.0, after moving the replication things out, there is no > > persistent data on zookeeper now. So it is possible to move off > > zookeeper now, of course, we still need at least something like etcd, > > as we need an external system to track the living region servers... > > > > And I think the registry interface is for connecting to a HBase > > cluster from outside, it does not need to know the internal > > implementation of HBase, i.e, whether to make use of zookeeper. > > For me, I think a possible problem is that we expose the meta location > > in registry interface, since the splittable meta feature has been > > restarted, if later we support multiple meta regions in HBase, we will > > need extra works if we still want to keep the zk based registry... > > > > Thanks. > > > > Nick Dimiduk <ndimi...@apache.org> 于2024年3月1日周五 16:25写道： > > > > > > 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> > > > > ------------------------------ > > > > ------------------------------ > > > > > > > > > -- > *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> > ------------------------------ > ------------------------------ >
