The thread has gone quiet, so then do we have consensus? Our objective is to remove ZooKeeper from our public interface, remaking it as an internal concern. Connecting to a cluster via ZooKeeper quorum will be considered deprecated starting in 2.6. Our default connection mechanism will switch to via RPC in 3.0 And finally we intend to remove the ZooKeeper connection mechanism from client-facing APIs in 4.0.
I'll prepare some patches. On Mon, Mar 4, 2024 at 1:19 PM Bryan Beaudreault <bbeaudrea...@apache.org> wrote: > I’d say let’s do it. But if we want to do it for 2.6.0 then it’s be great > to put up a PR asap so it doesn’t block the release. I’m hoping to get the > RC0 out this week > > On Mon, Mar 4, 2024 at 4:41 AM Nick Dimiduk <ndimi...@apache.org> wrote: > > > On Fri, Mar 1, 2024 at 6:12 PM Andrew Purtell <apurt...@apache.org> > wrote: > > > > > I disagree. We can keep the current defaults AND deprecate > > > ZKConnectionRegistry as a warning to users that things will change in > > > future releases. That is the entire reason for deprecation, yes? > > > > > > > Indeed. For me, there is value in introducing the Deprecation warnings as > > early as possible, to give folks forewarning. So I suggest that we mark > it > > deprecated in 2.6, it is no longer the default connection mechanism in > 3.0, > > and it is removed in 4.0. > > > > On Fri, Mar 1, 2024 at 4:53 AM Nick Dimiduk <ndimi...@apache.org> wrote: > > > > > > > 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> > > > > > ------------------------------ > > > > > ------------------------------ > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > >
