[
https://issues.apache.org/jira/browse/HBASE-22823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-22823:
-----------------------------------
Description:
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.
> 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
> Priority: Minor
>
> 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)
