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 >
