> I agree that what we publish as metrics out over our jmx interface is
public. What is interesting though is that all Metrics implementation
classes are IA.private. And what we push out to operators is read-only.
Yep the problem as I see it is those metrics that are published via Hadoop
metrics o
Here, and on the JIRAs. Maybe 'conversation' is an optimistic way to
describe the state of things so far. We should have a separate thread for
it. As far as I know, we don't have one yet.
On Mon, Oct 9, 2017 at 11:24 AM, Stack wrote:
> On Fri, Oct 6, 2017 at 9:10 AM, Stack wrote:
>
> >
>
On Fri, Oct 6, 2017 at 9:10 AM, Stack wrote:
>
>
>
>> Some changes have been proposed that removes access to metrics (e.g.
>> RegionMetrics, MasterMetrics). Right now coprocessors can bypass core
>> function and replace it. Until and unless we remove the bypass semantic
>> (under discussion)
I think at least at the Store level we want to admit the possibility of
alternate implementations.
Region is pushing it. It would be ideal of course to have nice clean
interfaces which could be mocked or given to new implementations, but the
legacy aspects of the code base probably make that more
On Thu, Oct 5, 2017 at 9:30 AM, Josh Elser wrote:
> (I think I understand the problems enough to comment, but, admittedly, my
> 5minute read is probably lacking)
>
>
Thanks for chiming-in Josh.
> I think the only argument against what you all have outlined here is if,
> in the future, we have
On Wed, Oct 4, 2017 at 3:51 PM, Andrew Purtell wrote:
> I think it is fine to rebrand these interfaces as for coprocessors and tag
> them LP(COPROC):
>
> Region (use HRegion in internals)
>
> Store (use HStore in internals)
>
> MasterServices (use HMaster in internals)
>
> RegionS
(I think I understand the problems enough to comment, but, admittedly,
my 5minute read is probably lacking)
I think the only argument against what you all have outlined here is if,
in the future, we have some intent to create new implementations of
HRegion or HStore. If that's the case, Region
I think it is fine to rebrand these interfaces as for coprocessors and tag
them LP(COPROC):
Region (use HRegion in internals)
Store (use HStore in internals)
MasterServices (use HMaster in internals)
RegionServerServices (use HRegionServer in internals)
and pare them down. This
A bunch of us are making good progress on the next alpha release,
hbase-2.0.0-alpha-4. The theme for this release is "Fixing the Coprocessor
API", mostly undoing access accidentally granted Coprocessors. I'm talking
out loud about a particularly awkward item here rather than in a comment up
in JIRA
