[ 
https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392269#comment-17392269
 ] 

Geoffrey Jacoby commented on HBASE-26158:
-----------------------------------------

A correction: the Kafka minicluster in my example above is using the Kafka 
EmbeddedZookeeper class and not sharing a ZK quorum with the HBase minicluster 
or custom process. (Which do share with each other) So let's ignore it for this 
discussion. 

The reason why we can't use curator-test is that there's no way I can see to 
inject HBaseTestingUtility with a curator-test TestingServer instead of an 
MiniZookeeperCluster. So we have to inject a MiniZookeeperCluster into the 
custom process's in-process test harness. The test just wouldn't work with 
curator-test. (There _definitely_ isn't a way to do it with the 
TestingHBaseCluster, which is one of many reasons I proposed HBASE-26115.)

HBase didn't have a "duty" to make MiniZookeeperCluster -- it could use 
curator-test internally and allow tests to inject a TestingServer in the HBTU 
-- but it did, and deliberately exposed it as IA.Public, and downstream users 
are allowed to rely on that. 

It _is_ literally designed to allow end users the ability to start a ZK to 
write UT. That's what IA.Public means. :-)





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

Reply via email to