Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Nick Dimiduk]

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 
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  wrote:
>
> > On Fri, Mar 1, 2024 at 6:12 PM Andrew Purtell 
> 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  wrote:
> > >
> > > > On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth
>  > >
> > > > 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)  >
> > > > 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  于2024年3月1日周五 16:25写道：
> > > > > > >
> > > > > > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth
> > >  > > > >
> > > > > > 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 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Bryan Beaudreault]

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

> On Fri, Mar 1, 2024 at 6:12 PM Andrew Purtell  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  wrote:
> >
> > > On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth  >
> > > 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) 
> > > 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  于2024年3月1日周五 16:25写道：
> > > > > >
> > > > > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth
> >  > > >
> > > > > 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 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Nick Dimiduk]

On Fri, Mar 1, 2024 at 6:12 PM Andrew Purtell  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  wrote:
>
> > On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth 
> > 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) 
> > 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  于2024年3月1日周五 16:25写道：
> > > > >
> > > > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth
>  > >
> > > > 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,
> > > > > > 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Andrew Purtell]

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?

On Fri, Mar 1, 2024 at 4:53 AM Nick Dimiduk  wrote:

> On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth 
> 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) 
> 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  于2024年3月1日周五 16:25写道：
> > > >
> > > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth  >
> > > 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 
> > > 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
> > 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Duo Zhang]

May be deprecated in 3.0.0?

Nick Dimiduk  于2024年3月1日周五 20:52写道：
>
> On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth 
> 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)  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  于2024年3月1日周五 16:25写道：
> > > >
> > > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth 
> > > 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 
> > > wrote:
> > > > >
> > > > > > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> > > > > 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 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Nick Dimiduk]

On Fri, Mar 1, 2024 at 1:39 PM Istvan Toth 
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)  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  于2024年3月1日周五 16:25写道：
> > >
> > > On Fri, 1 Mar 2024 at 07:47, Istvan Toth 
> > 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 
> > wrote:
> > > >
> > > > > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> > > > 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.
> 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Istvan Toth]

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.

Istvan

On Fri, Mar 1, 2024 at 10:12 AM 张铎(Duo Zhang)  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  于2024年3月1日周五 16:25写道：
> >
> > On Fri, 1 Mar 2024 at 07:47, Istvan Toth 
> 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 
> wrote:
> > >
> > > > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> > > 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 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Duo Zhang]

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  于2024年3月1日周五 16:25写道：
>
> On Fri, 1 Mar 2024 at 07:47, Istvan Toth  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  wrote:
> >
> > > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> > >
> > >
> > >
> > >
> > > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> > 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 

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Nick Dimiduk]

On Fri, 1 Mar 2024 at 07:47, Istvan Toth  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  wrote:
>
> > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> >
> >
> >
> >
> > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> 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 
> [image: Cloudera] 
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
> --
>

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Andrew Purtell]

Deprecation does not mean disabling, it does not even mean changing the
default.

On Thu, Feb 29, 2024 at 10:49 PM Istvan Toth 
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 
> wrote:
>
> > +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
> >
> >
> >
> >
> > On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk 
> 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 
> [image: Cloudera] 
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
> --
>


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

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Istvan Toth]

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

> +1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.
>
>
>
>
> On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk  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 
[image: Cloudera] 
[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 
--
--

Re: [DISCUSS] Deprecating zookeeper-based client connectivity

[Andrew Purtell]

+1 for deprecating ZKConnectionRegistry beginning with/in 2.6.0.




On Thu, Feb 29, 2024 at 2:30 AM Nick Dimiduk  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