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 > > >
