[jira] [Comment Edited] (HBASE-20595) Remove the concept of 'special tables' from rsgroups

2018-05-17 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479457#comment-16479457
 ] 

Andrew Purtell edited comment on HBASE-20595 at 5/17/18 5:53 PM:
-

bq. Or, we institute a blanket rule that core and all extensions that need a 
"special table" must put them into the 'hbase:' namespace, so the 
TableName#isSystemTable() test will return TRUE for all, and then rsgroups 
simply needs to test for that.

This is what I am thinking as far as how we achieve removal of the 'special 
tables' concept. Special == system. I haven't looked at all of the places where 
we create such tables though to determine if it is a compat problem, a move of 
the table to the system namespace. Pretty sure the security coprocessors are 
fine. Quotas is only in trunk so that would be ok too. Anyway, any objections 
to this?


was (Author: apurtell):
bq. Or, we institute a blanket rule that core and all extensions that need a 
"special table" must put them into the 'hbase:' namespace, so the 
TableName#isSystemTable() test will return TRUE for all, and then rsgroups 
simply needs to test for that.

This is what I am thinking as far as how we achieve removal of the 'special 
tables' concept. Special == system. I haven't looked at all of the places where 
we create such tables though to determine if it is a compat problem. Pretty 
sure the security coprocessors are fine. Quotas is only in trunk so that would 
be ok too. Anyway, any objections to this?

> Remove the concept of 'special tables' from rsgroups
> 
>
> Key: HBASE-20595
> URL: https://issues.apache.org/jira/browse/HBASE-20595
> Project: HBase
>  Issue Type: Task
>  Components: Region Assignment, rsgroup
>Reporter: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0
>
>
> Regionserver groups needs to specially handle what it calls "special tables", 
> tables upon which core or other modular functionality depends. They need to 
> be excluded from normal rsgroup processing during bootstrap to avoid circular 
> dependencies or errors due to insufficiently initialized state. I think we 
> also want to ensure that such tables are always given a rsgroup assignment 
> with nonzero servers. (IIRC another issue already raises that point, we can 
> link it later.)
> Special tables include:
> * The system tables in the 'hbase:' namespace
> * The ACL table if the AccessController coprocessor is installed
> * The Labels table if the VisibilityController coprocessor is installed
> * The Quotas table if the FS quotas feature is active
> Either we need a facility where "special tables" can be registered, which 
> should be in core. Or, we institute a blanket rule that core and all 
> extensions that need a "special table" must put them into the 'hbase:' 
> namespace, so the TableName#isSystemTable() test will return TRUE for all, 
> and then rsgroups simply needs to test for that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (HBASE-20595) Remove the concept of 'special tables' from rsgroups

2018-05-17 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479450#comment-16479450
 ] 

Andrew Purtell edited comment on HBASE-20595 at 5/17/18 5:49 PM:
-

bq. we'll probably need to document "can't turn on rsgroup feature" as a 
limitation of single-node deployments.

Ah, no, better that the constraint that system tables cannot be placed into the 
same rsgroup as user tables be what is optional, and allow single node 
deployments to put everything into "default"



was (Author: apurtell):
bq. we'll probably need to document "can't turn on rsgroup feature" as a 
limitation of single-node deployments.

Ah, no, better that the constraint that system tables cannot be placed into the 
same rsgroup as user tables be what is optional.


> Remove the concept of 'special tables' from rsgroups
> 
>
> Key: HBASE-20595
> URL: https://issues.apache.org/jira/browse/HBASE-20595
> Project: HBase
>  Issue Type: Task
>  Components: Region Assignment, rsgroup
>Reporter: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0
>
>
> Regionserver groups needs to specially handle what it calls "special tables", 
> tables upon which core or other modular functionality depends. They need to 
> be excluded from normal rsgroup processing during bootstrap to avoid circular 
> dependencies or errors due to insufficiently initialized state. I think we 
> also want to ensure that such tables are always given a rsgroup assignment 
> with nonzero servers. (IIRC another issue already raises that point, we can 
> link it later.)
> Special tables include:
> * The system tables in the 'hbase:' namespace
> * The ACL table if the AccessController coprocessor is installed
> * The Labels table if the VisibilityController coprocessor is installed
> * The Quotas table if the FS quotas feature is active
> Either we need a facility where "special tables" can be registered, which 
> should be in core. Or, we institute a blanket rule that core and all 
> extensions that need a "special table" must put them into the 'hbase:' 
> namespace, so the TableName#isSystemTable() test will return TRUE for all, 
> and then rsgroups simply needs to test for that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (HBASE-20595) Remove the concept of 'special tables' from rsgroups

2018-05-16 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478153#comment-16478153
 ] 

Andrew Purtell edited comment on HBASE-20595 at 5/16/18 9:42 PM:
-

The issue I was thinking of was HBASE-20500 which maintains one server in the 
'default' group, but that is not the full scope of what we should have. We 
should guarantee the placement, specifically, of "special tables" into a 
rsgroup that must always have a nonzero number of servers, and not assume that 
will be the 'default' group. In fact I think we should have two default 
rsgroups, very similar to how we do namespacing: a "default" group into which 
goes all user level stuff not otherwise specified; and a system group into 
which goes system/special tables (in namespace terms, akin to the 'hbase' 
namespace). Special tables should not be allowed to move into rsgroups for user 
tables. 


was (Author: apurtell):
The issue I was thinking of was HBASE-20500 which maintains one server in the 
'default' group, but that is not the full scope of what we should have. We 
should guarantee the placement, specifically, of "special tables" into a 
rsgroup that must always have a nonzero number of servers, and not assume that 
will be the 'default' group. In fact I think we should have two default 
rsgroups, very similar to how we do namespacing: a "default" group into which 
goes all user level stuff not otherwise specified; and a system group into 
which goes system/special tables (in namespace terms, akin to the 'hbase' 
namespace)

> Remove the concept of 'special tables' from rsgroups
> 
>
> Key: HBASE-20595
> URL: https://issues.apache.org/jira/browse/HBASE-20595
> Project: HBase
>  Issue Type: Task
>  Components: Region Assignment, rsgroup
>Reporter: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0
>
>
> Regionserver groups needs to specially handle what it calls "special tables", 
> tables upon which core or other modular functionality depends. They need to 
> be excluded from normal rsgroup processing during bootstrap to avoid circular 
> dependencies or errors due to insufficiently initialized state. I think we 
> also want to ensure that such tables are always given a rsgroup assignment 
> with nonzero servers. (IIRC another issue already raises that point, we can 
> link it later.)
> Special tables include:
> * The system tables in the 'hbase:' namespace
> * The ACL table if the AccessController coprocessor is installed
> * The Labels table if the VisibilityController coprocessor is installed
> * The Quotas table if the FS quotas feature is active
> Either we need a facility where "special tables" can be registered, which 
> should be in core. Or, we institute a blanket rule that core and all 
> extensions that need a "special table" must put them into the 'hbase:' 
> namespace, so the TableName#isSystemTable() test will return TRUE for all, 
> and then rsgroups simply needs to test for that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)