[
https://issues.apache.org/jira/browse/HBASE-22823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909958#comment-16909958
]
Duo Zhang commented on HBASE-22823:
-----------------------------------
Oh I haven't seen this one. I do not think we should mark an implemention class
IA.Public. If you want to do this please provide an interface first. We have
been fighting with the public implementation class all the time so please do
not go backward...
And it is not introduced by HBASE-17930, by default, no IA annotation means
IA.Private, not IA.Public.
I think we need to sink all the pending RCs and reconsidering this.
> Mark Canary as Public/Evolving
> ------------------------------
>
> Key: HBASE-22823
> URL: https://issues.apache.org/jira/browse/HBASE-22823
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Assignee: Caroline
> Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.2.1, 2.1.6, 1.3.6, 1.4.11
>
> Attachments: HBASE-22823.branch-1.000.patch,
> HBASE-22823.branch-2.000.patch, HBASE-22823.master.000.patch
>
>
> Canary is marked as a Private class. Its interfaces could change at any time.
> Should we change the annotation on Canary to Public/Evolving? Or add
> annotations on some of these subtypes? I think it depends on how we think
> Canary results should be consumed.
> In our production we find that scraping logs and parsing them is brittle and
> not scalable. Although the scalability issue is more to do with the totality
> of logs from a Hadoopish stack, if you run HBase then you have this problem,
> and you wouldn't be using the canary if you didn't run HBase. We have a tool
> that embeds the Canary and calls various methods and takes actions without
> needing a round trip to the logs and whatever aggregates them.
> I propose we promote Canary to Public/Evolving.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
