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

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

I stand by my point that so long as HBase has a mini ZooKeeper cluster, it 
should remain IA.Public so that downstream users don't have to wrestle with 
reconciling dependencies or maintaining internal forks. 

I don't think I've heard yet a practical example of something bad that occurs 
if it remains IA.Public -- you seem to dislike it because of a theory of what 
HBase "is" and "is not". Given that you don't want to get rid of or change the 
class, what's the real-world harm in keeping the IA as is? I've tried to give 
practical examples of bad things that will happen if it's no longer IA.Public. 

Here's another example, from just last week. Tephra is a subproject of Phoenix 
that does distributed transactions for both HBase and Phoenix. It was 
originally an incubating Apache project that Phoenix later adopted. Tephra 
chose to use Apache Twill's ZK minicluster for its tests. But Twill is in the 
Attic now and its dependencies are old. Trying to use newer versions of Tephra 
as dependencies with multiple legacy (4.x) Phoenix versions (which don't shade 
their dependencies very well) is _really_ hard. If Tephra had chosen to use 
HBase's ZK minicluster instead, this would be much easier. 

As you say, HBase is trying to get rid of ZK dependencies, so it's totally 
reasonable for HBase to deprecate its own MiniZookeeperCluster and adopt 
another project's. Then downstream projects can use the same well-tested 
solution that HBase uses; it's wouldn't be a lot of extra work for them. And if 
HBase ever does deprecate ZK support entirely, as I think Kafka is trying to 
do, of course any testing infrastructure around ZK would get deprecated too. No 
objection to either!

But in the meantime, downstream developers should be able to use the same APIs 
as HBase does to do the same sort of testing. Most tests are simple, but not 
all, and it's the hard ones I worry about.

Happy to continue the conversation here or on the dev list to get other 
opinions and perspectives if you'd like. I'd like to find consensus and avoid 
using my first committer veto if I can. But so far I haven't heard any benefit 
to HBase that outweighs the harm to downstream devs.

> 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