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:22:12 GMT


Christopher Tubbs commented on ACCUMULO-3375:

So, there's a few reasons why I think we should not do this:

# 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?)
# 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.
# The user database is typically very small, and infrequently updated. The idea of using an
Accumulo table to store this seems a bit overkill.

Some of this might be a little bit easier with the system user, but this would be an enormous
change, and I don't see a lot of value from it. I do see the potential to do it very badly
that kills performance or breaks security. If the ZK implementation is not sufficient, we're
probably better off improving the pluggable security APIs added in ACCUMULO-259.

If anybody is interested in pursuing this, I'd like to review the design.

> 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