[jira] [Comment Edited] (HBASE-26158) MiniZooKeeperCluster should not be IA.Public

["Geoffrey Jacoby (Jira)" <ji...@apache.org>]

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