[
https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392613#comment-17392613
]
Geoffrey Jacoby commented on HBASE-26158:
-----------------------------------------
I don't know the details of the Hadoop and HBase community's decisions that led
to the forking of metrics and http, so I can't offer an informed opinion on it.
As a general rule, I consider permanent forks of code such as those cases a
last resort.
What you describe isn't dogfooding, at least as I understand the term.
Say I need to coordinate between two in-process services via ZK, or to kill a
ZK quorum to test some error path code.
If I'm writing code for the HBase project itself, under this JIRA's proposal I
would use the MiniZookeeperCluster.
If I'm writing code for anything else, under this JIRA's proposal I would need
to use curator-test, and manage the dependency myself, or fork the
MiniZookeeperCluster, and have to keep it up to date with any changes from
upstream forever.
Different people would be using different APIs to do the same thing. The fact
that in _other_, simpler use cases they'd go through the same code path doesn't
change this.
> 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)
