Filed HBASE-26098. Geoffrey Jacoby <gjac...@apache.org> 于2021年7月20日周二 上午3:14写道：
> Can this be a [DISCUSS] rather than a [NOTICE]? The implications for > downstream projects (both Phoenix and many internal projects) are large, > and it seems like something that needs broader discussion before being set > in stone. The HBaseTestingUtility is used extensively in Phoenix, as well > as in many internal projects at my dayjob (some directly and some through > Phoenix's BaseTest wrapping of HBTU) -- it's quite useful. > > The idea of a better-encapsulated, easier-to-use HBase testing utility is a > good one, and the TestingHBaseCluster interface looks like a definite > improvement. However, I notice at least one large gap right away: there > doesn't appear to be a way to inject a custom Configuration object into the > test cluster, which is a very common pattern. (Example: run a test suite > twice with a new minicluster each time, once with a flag off and then on.) > This seems like a simple fix. > > More concerning is the underlying assumption of the change, that only the > HBase project, and perhaps Phoenix, will ever need to write a test of > server-side components. That's simply not the case, because HBase has many > integration points that allow downstream developed code to run in > server-side processes. > > These include: > Coprocessor Observers and Endpoints > Replication Endpoints > MapReduce integration (which acts as a client from HBase's perspective but > runs within YARN services) > > In addition, Phoenix supports user-defined functions (UDFs) which I believe > can run server-side within a coproc in certain query plans. > > The change assumes that no one will ever need direct access to the testing > utility's internal ZooKeeper, MR, or DFS services, but this seems relevant > to failure scenario tests of both Replication Endpoints and MapReduce jobs. > The Admin API may be able to replace quite a lot of existing logic going > forward, and many existing tests already use it rather than the test > utility directly. But there are literally thousands of downstream tests to > analyze across many different organizations and institutions to verify that > nothing important is being lost, and that will take time. Just leaving a > reference to the old, lower-level HBTU as a public property of the new > interface seems lower-risk to me. What are the gains from hiding the > existing HBTU? > > Geoffrey > > > > On Sun, Jul 18, 2021 at 9:44 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > Please see the discussion in > > https://issues.apache.org/jira/browse/HBASE-13126 > > > > And final work is done in > > https://issues.apache.org/jira/browse/HBASE-26081 > > https://github.com/apache/hbase/pull/3478 > > > > The original HBaseTestingUtility has been renamed to HBaseTestingUtil, > and > > MiniHBaseCluster has been renamed to SingleProcessHBaseCluster. Now they > > are not expected to be used by end users any more. We marked it as > > IA.LimitedPrivate("Phoenix"), as maybe the Phoenix project may still need > > to test something internal to HBase. > > > > Anyway, we encourage every downstream projects(including Phoenix) to try > to > > make use of the new TestingHBaseCluster introduced in > > https://issues.apache.org/jira/browse/HBASE-26080 > > > > We can keep improving it if the current API set is not enough. > > > > ==== 简略的中文版通知，非直译 ==== > > > > HBaseTestingUtility 已经在 3.0.0 中被标记为 Deprecated，请所有用户尽量尝试使用在 HBASE-26080 > > 中引入的 TestingHBaseCluster。有任何需求请随时反馈，我们会持续优化。 > > >
