accumulo-notifications mailing list archives

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


Josh Elser commented on ACCUMULO-3375:

Thanks for the thoughts, [~ctubbsii]. 

bq. This could create a circular dependency (how do we authenticate users so they can interact
with the metadata tables? who can scan the user table?)

My gut reaction was that the !SYSTEM user would continue to be "special", and perhaps not
have an entry in said table. I think that would get around most of the cyclic issues. Other
permission issues would still need to be sorted out.

bq. There's no sense of consistency... and any real-time attempts to be consistent would kill
performance: we'd have to scan this table every time we do any other operation: create table
now triggers a table scan.

Pretty sure our tables are consistent ;). Turning on the datablock cache for this table (like
the metadata table) should alleviate most pain, but metrics would be needed. IsolatedScanners
could also be used if we need strong consistency when scanning across a row.

bq. The user database is typically very small, and infrequently updated. The idea of using
an Accumulo table to store this seems a bit overkill.

I think I thought the same thing initially, but how much of that is because of how we have
implemented the user system to begin with? Consider a large organization with authentication
via an external system like LDAP or Kerberos. Having a scalable store provided by us would
be nicer for all those permissions/authorizations/etc. Need some more measurable numbers behind

> Move user and permission data into a table
> ------------------------------------------
>                 Key: ACCUMULO-3375
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Josh Elser
> 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