Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

On Thu, Oct 26, 2017 at 1:52 PM Josh Elser wrote: > That's the million-dollar question, now isn't it! :) > > Something to hbase-metrics-api/README.md? A chapter in the book? > In the Javadoc makes the most sense to me. I don’t think people would check the book. Apply, where

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

On 10/26/17 1:55 PM, Apekshit Sharma wrote: bq. .integration with metrics-library1 to support the metrics platform for their $business1. $business2 might want to use metrics-library2 Makes sense Josh. bq. One final concern, bundling our "default" DropwizardMetrics 3-based

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

That's the million-dollar question, now isn't it! :) Something to hbase-metrics-api/README.md? A chapter in the book? Happy to try to translate some of this info into something more "permanent" On 10/26/17 12:59 AM, Misty Stanley-Jones wrote: If we keep it as is, how and where can we capture

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

bq. .integration with metrics-library1 to support the metrics platform for their $business1. $business2 might want to use metrics-library2 Makes sense Josh. bq. One final concern, bundling our "default" DropwizardMetrics 3-based implementation could cause headaches for users who want to

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

If we keep it as is, how and where can we capture this knowledge to save future contributors from having to ask again? On Wed, Oct 25, 2017 at 9:22 AM Josh Elser wrote: > :) no worries, Appy. These are good questions. > > It really comes down to the question: would HBase ever

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

:) no worries, Appy. These are good questions. It really comes down to the question: would HBase ever provide multiple metrics implementations for users? As we know metrics in HBase now, there isn't any reason to support multiple implementations of metrics. We have one implementation which

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

That issue renamed a bunch of what used to be there only for hbase-hadoop-compat. HBASE-6405 is the start of the chain. Currently though I don't see any reason for them to be in separate modules unless we think hadoop will make another breaking change to the metrics classes. On Tue, Oct 24,

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

Hi Josh You're right that naming doesn't make it clear, but Enis added a really great description in README of hbase-metrics-api to explain what's in each module. However it's not obvious why are we splitting things into separate module, as opposed to say, separating implementation in a separate

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

Hey Appy, I think Enis essentially copied what I was originally trying to do. Up in Avatica[1], I made a similar API Maven module which just had interfaces. The implementation was them split up into a different module to avoid the implementation details of the API (specifically, using

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

Hey Elliott, good to see you around :) Btw, this is new stuff added in HBASE-9774 which was committed to only 2.0. Made it to 1.4 too later (HBASE-18060). -- Appy On Tue, Oct 24, 2017 at 4:16 PM, Elliott Clark wrote: > The weird module dance with reflection came from

Re: [DISCUSS] Merge hbase-metrics:oahh.metrics.impl into hbase-metrics-api

The weird module dance with reflection came from needing to extend inner hadoop classes on multiple different versions. This was back when HBase had to support hadoop < 1, hadoop 1.x, and hadoop 2.x. When we dropped older hadoop versions then things got easier. On Tue, Oct 24, 2017 at 3:09 PM,