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
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
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
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
>
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
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
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
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
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
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
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,
+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
12 matches
Mail list logo
