accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3375) Move user and permission data into a table
Date Mon, 01 Dec 2014 23:48:12 GMT


Christopher Tubbs commented on ACCUMULO-3375:

bq. My gut reaction was that the !SYSTEM user would continue to be "special", and perhaps
not have an entry in said table.

Right, that's basically what we have now.

bq. Pretty sure our tables are consistent ...

I don't mean consistency within the table. I mean consistent view of permissions between tables.
Imagine a BatchScanner over a few hundred tablets spread across a cluster, and now scanning
that triggers a few hundred requests to a single tablet to check a user's permissions. The
alternative is to not scan every time, and risk half of these failing because you recently
changed your password. Otherwise, all of these tablet servers are going to have to scan the
same tablet to check the user's permissions. With ZooKeeper, we can update the cache passively
with a watcher and get reasonably consistent views without the performance hit.

> Move user and permission data into a table
> ------------------------------------------
>                 Key: ACCUMULO-3375
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Josh Elser
>            Priority: Minor
> We currently use ZooKeeper to store the user database (name and password) in addition
to the authorizations and permissions for each user.
> ZooKeeper is designed for distributed configuration and synchronization/coordination
tasks; it is not designed to be a persistent store. In this case it would be better to use
a table to manage this information.
> I think this might reduce some complexity in managing that database, notably better recovery
if ZK dies for some reason. Having a table might trivialize import/export of the user database
(ACCUMULO-1722 is what made me think of this).

This message was sent by Atlassian JIRA

View raw message