[
https://issues.apache.org/jira/browse/HBASE-23055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012514#comment-17012514
]
Michael Stack commented on HBASE-23055:
---------------------------------------
bq. For the procedure store, it has an interface, so the damage to the whole
architecture can be limited. But meta is another story, and is even more
critical. We reference meta table descriptor everywhere in the code, not sure
if there are other implicit assumptions in the code.
Mishap in store impl and the cluster is hosed, unfixable. There will be little
solace that the store implementation is against an interface.
Default for this feature is no difference in operation. Regards implicit
assumptions in the code, perhaps, but would think full test suite run would
have turned up the worst offenders. In testing, looking for others.
bq. I think we’d better do this on feature branch, do more testing, fix
problems, and then merge it back.
It'll get more testing being in upcoming RC that it will having it out on
feature branch.
Any objection to the workings of the patch as is? It has been made less
ambitious than previous go around.
> Alter hbase:meta
> ----------------
>
> Key: HBASE-23055
> URL: https://issues.apache.org/jira/browse/HBASE-23055
> Project: HBase
> Issue Type: Task
> Reporter: Michael Stack
> Assignee: Michael Stack
> Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>
> hbase:meta is currently hardcoded. Its schema cannot be change.
> This issue is about allowing edits to hbase:meta schema. It will allow our
> being able to set encodings such as the block-with-indexes which will help
> quell CPU usage on host carrying hbase:meta. A dynamic hbase:meta is first
> step on road to being able to split meta.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)