stack commented on HBASE-16060:

.001 does the below. May I have a review please?

    HBASE-16060 1.x clients cannot access table state talking to 2.0 cluster

    This patch adds mirroring of table state out to zookeeper. HBase-1.x
    clients look for table state in zookeeper, not in hbase:meta where
    hbase-2.x maintains table state.

    The patch also moves and refactors the 'migration' code that was put in
    place by HBASE-13032.


    M hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
     Move table state migration code from Master startup out to
    TableStateManager where it belongs. Also start
    MirroringTableStateManager dependent on config.


     Move migration from zookeeper of table state in here. Also plumb in
    mechanism so subclass can get a chance to look at table state as we do
    the startup fixup full-table scan of meta.

     Bug-fix. Now we create regions in CLOSED state but we fail to check
    table state; were presuming table always enabled. Meant on startup
    there'd be an unassigned region that never got assigned.

     Test migration and mirroring.

> 1.x clients cannot access table state talking to 2.0 cluster
> ------------------------------------------------------------
>                 Key: HBASE-16060
>                 URL: https://issues.apache.org/jira/browse/HBASE-16060
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 2.0.0-beta-2
>         Attachments: 
> 0002-HBASE-16060-1.x-clients-cannot-access-table-state-ta.patch, 
> HBASE-16060.branch-2.001.patch, HBASE-16060.branch-2.002.patch
> Since table state is migrated to meta instead of zk in 2.0, 1.x clients 
> talking to 2.0 cluster cannot access the table state. This causes some weird 
> behavior since from a client perspective, {{Admin.isTableEnabled()}} and 
> {{Admin.isTableDisabled()}} both return false. 
> One option we can do is to add code in 1.x clients so that they can access 
> the table state in meta if needed. Otherwise, we can mirror the table state 
> in zk (while keeping meta as the source of truth) during 2.x lifecycle so 
> that any 1.x client can still work correctly. 

This message was sent by Atlassian JIRA

Reply via email to