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