[ https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392282#comment-17392282 ]
Geoffrey Jacoby commented on HBASE-26158: ----------------------------------------- You keep saying "HBase is not designed to do X" but not providing evidence. HBase is the result of many people's decisions and designs -- how do you know it's not designed to do this? The code and annotation certainly indicates it was, and the code is the concrete form of a design. The problem with having HBase continue to use MiniZookeeperCluster internally, but allowing TestingServer to be passed in via config, is that it makes tests using it that way unsupported. My worry is that if I have a problem, the HBase community might say, "TestingServer is owned by curator, we don't use it at all, so go ask the Curator community", while the Curator community would know nothing about the HBase minicluster, and probably point me back to HBase. Now, if we want the HBase minicluster to formally adopt curator-test internally and deprecate MiniZookeeperCluster because MiniZookeeperCluster is now redundant given curator-test's existence, that sounds fine -- but having a supported option for internal tests and an unsupported option for end-user tests just seems like it would lead to lots of problems for end-users. > 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)