[
https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392569#comment-17392569
]
Geoffrey Jacoby edited comment on HBASE-26158 at 8/3/21, 10:12 PM:
-------------------------------------------------------------------
I agree the curator version compatibility is a big issue here too. There's a
curator.version in the HBase pom.xml, but it only seems to be used for a coproc
example. There's little to no guidance to end users about what version of
curator are compatible with what versions of HBase.
Again, I think [~zhangduo] makes a good point that with a publicly available ZK
minicluster, the MiniZookeeperCluster may no longer be necessary. It's working
fine both internally and externally, so I don't feel strongly that it needs to
go, but I wouldn't mind if it did -- so long as it was deprecated both
externally AND internally, via the usual deprecation method.
I believe that would be, in HBase 3.0:
1. Take on curator-test as a formal dependency of HBase. This requires figuring
out which version to use, excluding conflicting transitive dependencies, etc
2. Probably shade it into hbase-thirdparty?
3. Do HBASE-26167 to allow for overriding ZK with an external embedded ZK
quorum.
4. Switch TestingHBaseCluster and HBTU to use curator-test by default
5. Fix any HBase tests that break because of this effort
6. Fix any bugs found in curator-test because of this effort
7. Deprecate the MiniZookeeperCluster and the methods in HBTU that reference it
(but still support them during the 3.x cycle).
In HBase 4.0:
1. Delete the MiniZookeeperCluster and the methods in HBTU that reference it.
At this point, HBase will have offloaded its embedded ZK onto a ZK-based
project, similarly to how MiniDFSCluster is I believe part of HDFS. Which would
be good.
On the other hand, if that sounds like a lot of work compared to the
benefit...please remember that that aside from HBASE-26167 and the actual
deprecation JIRA, that's almost the same work you're asking end-users to do.
was (Author: gjacoby):
I agree the curator version compatibility is a big issue here too. There's a
curator.version in the HBase pom.xml, but it only seems to be used for a coproc
example. There's little to no guidance to end users about what version of
curator are compatible with what versions of HBase.
Again, I think [~zhangduo] makes a good point that with a publicly available ZK
minicluster, the MiniZookeeperCluster may no longer be necessary. It's working
fine both internally and externally, so I don't feel strongly that it needs to
go, but I wouldn't mind if it did -- so long as it was deprecated both
externally AND internally, via the usual deprecation method.
I believe that would be, in HBase 3.0:
1. Take on curator-test as a formal dependency of HBase. This requires figuring
out which version to use, excluding conflicting transitive dependencies, etc
2. Probably shade it into hbase-thirdparty?
3. Do HBASE-26167 to allow for overriding ZK with an external embedded ZK
quorum.
4. Switch TestingHBaseCluster and HBTU to use curator-test by default
5. Fix any HBase tests that break because of this effort
6. Fix any bugs found in curator-test because of this effort
5. Deprecate the MiniZookeeperCluster and the methods in HBTU that reference it
(but still support them during the 3.x cycle).
In HBase 4.0:
1. Delete the MiniZookeeperCluster and the methods in HBTU that reference it.
At this point, HBase will have offloaded its embedded ZK onto a ZK-based
project, similarly to how MiniDFSCluster is I believe part of HDFS. Which would
be good.
On the other hand, if that sounds like a lot of work compared to the
benefit...please remember that that aside from HBASE-26167 and the actual
deprecation JIRA, that's almost the same work you're asking end-users to do.
> MiniZooKeeperCluster should not be IA.Public
> --------------------------------------------
>
> Key: HBASE-26158
> URL: https://issues.apache.org/jira/browse/HBASE-26158
> Project: HBase
> Issue Type: Sub-task
> Components: API, test
> Reporter: Duo Zhang
> Priority: Major
>
> End users do not need to test HBase when zookeeper is broken. And if users
> want to start only a zookeeper cluster, they can just use curator-test, so I
> do not think we should expose this class as IA.Public.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
