[
https://issues.apache.org/jira/browse/HBASE-24609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213571#comment-17213571
]
Michael Stack commented on HBASE-24609:
---------------------------------------
bq.
bq.
bq. Is this plan written down anywhere?
bq.
bq. No, but I think this is a general rule. Do not put code in a place where no
one should use it.
This is a rule that is so general, it has no meaning. Or if it has meaning,
then you have a lot of rewriting to do and you should explain why MTA and why
now?
I asking regards the general refactoring that is going on here, is there a plan
written down? I can discern some notions but lack of plan or outline of
direction makes review hard since I don't know what you are trying to achieve.
bq.
bq. I'm afraid not. Maybe we could try to avoid using MTA but favored node
balancer will store the favored nodes in the 'info' family, with a 'fn'
qualifier.
The FN balancer hasn't worked in years if it ever worked. Lets deprecate and
remove.
{quote}
Maybe balancer is in wrong place in the dependency hierarchy then?
I do not think so. We are trying to move code out of hbase-server as much as if
possible. We have hbase-zookeeper, hbase-replication, hbase-http. I think we
should do the same for hbase-balancer. I do not think this should be reverted
only because we do not want to put MTA in hbase-balancer.{quote}
Its ok. You misunderstood or more likely, I did not explain properly. Its not
important (see above note on FN Balancer -- addressing that seems more
important especially if is is only place balancer is writing meta... lets shut
it down)
{quote}Will file an issue to justify the javadoc of related classes.
{quote}
Thanks. Will help those of us trying to follow along (I arrived here because I
followed ' HBASE-24608 Introduce a CatalogAccessor ' and arrived here.
{quote}I think 'accessing meta' is usually a 'fake ' requirement. What you
really want are 'get all regions of a table', 'update the location of a
region', 'lookup the location of a region' etc. Although they are stored in
hbase:meta, but in different places we have different ways to optimize it
right? At client side, we have region location cache, and at master side, we
cache everything in memory. That's why I want to completely remove the MTA.
{quote}
This all sounds great. Would love to participate.
bq. I would define it as 'Remove the modification methods in MTA and
developpers should always use RSS to modify region state at master side'.
Ok. Sounds good. Maybe an issue that says that rather than it coming out only
after digging in (its not mentioned in the description on this issue nor in the
release notes....). Again, just trying to figure out what is going on if only
to do good review and support the effort.
bq. Was I using wrong words again? It seems that you completely ignored my
comments about the CatalogFamilyFormat... It does not contain any modification
methods, just the data format related methods about the how we store data in
the 'info' family.
So, it should be called InfoColumnFamilyFormat according to your note above?
And you call it a parser in your description too? 'Family' means nothing in
hbase. We use the term ColumnFamily?
bq. And I also described why I call it 'Catalog'.
Yeah, seems 'off' going by how it is used elsewhere.
bq. I do not see your objections on HBASE-11288.
Different context over there. Don't see how it even relates.
> Move MetaTableAccessor out of hbase-client
> ------------------------------------------
>
> Key: HBASE-24609
> URL: https://issues.apache.org/jira/browse/HBASE-24609
> Project: HBase
> Issue Type: Task
> Components: amv2, Client, meta
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> On master branch we have AsyncMetaTableAccessor which is used at client side
> and MetaTableAccessor has lots of internal methods for implementing
> assignment, which is not part of our client code.
> So let's move it to hbase-server, and in the future, maybe in hbase-balancer?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
