stack commented on HBASE-16060:

With patch in place...

hbase(main):002:0> is_enabled 'TestTable'
0 row(s) in 0.1240 seconds

hbase(main):003:0> is_enabled 'disable'
0 row(s) in 0.0230 seconds

hbase(main):004:0> is_disabled 'disable'
0 row(s) in 0.0190 seconds

hbase(main):005:0> is_disabled 'TestTable'
0 row(s) in 0.0250 seconds

'disable' is a disabled table.

Playing more. The migration of table state from hbase-1.x. zookeepers is 
something we want and we have something courtesy of HBASE-13032 but it deleted 
all zk table state when done which messes up what this patch is trying to do.

> 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
> 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