accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Updated] (ACCUMULO-802) table namespaces
Date Fri, 05 Jul 2013 20:19:48 GMT


Christopher Tubbs updated ACCUMULO-802:

    Attachment: ACCUMULO-802.v3.patch

A few additions to the v2 patch:

# Don't keep both a {code}{ZKROOT}/namespaces/{namespaceId}/tables{code} and a {code}{ZKROOT}/tables/{tableId}/namespace{code}
It makes things more complex when we have to maintain two structures for the same information,
and will result in an inability to determine which is the authoritative source consistently
if they diverge (we had this problem with tables in ZK and in the metadata table awhile back).
I prefer the latter, because I think the table's own configuration should be the authoritative
source of who has additional configuration for it.
# Make sure the bytes written to ZooKeeper from strings (table namespace IDs, namespace names),
are written as UTF8 bytes, and read back as UTF8 bytes. (For example, in Tables.getNamespace(Instance,
String);); Since we don't have JDK7's UTF_8 constant, use our own: Constants.UTF8.
# (Optional) In the master.thrift file, please ensure that params in new methods have sequential
param IDs (1,2,3...). It's easier to read, and that makes it easier to add new params to thrift
RPC methods that is backwards-compatible. Don't change old methods, though.
# Avoid adding javadocs that don't add value (example: '@throws Exception' param without a
# If you add a TODO, please include the Accumulo JIRA number in the comment so it can be tracked
(example: '// TODO security check (ACCUMULO-1479)')
# Update the WIRE_VERSION to 3, and put the upgrade code in the if block. The data version
was already incremented to account for the root table separation, so any upgrade checks based
on the data version should work seamlessly.

I'm adding [^ACCUMULO-802.v3.patch] with some of my recommendations.
> table namespaces
> ----------------
>                 Key: ACCUMULO-802
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>            Reporter: Eric Newton
>            Assignee: Sean Hickey
>             Fix For: 1.6.0
>         Attachments: ACCUMULO-802.v0.patch, ACCUMULO-802.v1.patch, ACCUMULO-802.v2.patch,
ACCUMULO-802.v3.patch, table-namespaces-README.txt, table-namespaces-README.v1.txt
> A large cluster is a valuable shared resource.  The current permission system and simple
table naming structure does not allow for delegation of authority and safe partitioning within
this shared resource.
> Use cases:
>  # create a namespace (like "test") and delegate the {{grant}} permission to tables created
in that namespace to a user that would manage those tables. Presently, {{grant}} is never
>  # create simple "test" and "production" namespaces that are trivial for users to switch
between.  For example, instead of having tables "test_index" and "test_documents" the client
would support "index" and "documents" with an API to support switching trivially between the
the different environments.
>  # create a set of tables in a namespace called "latest"  This namespace is re-created
periodically with a map-reduce job.  If code changes inadvertently create a corrupt "latest,"
users can switch to the set of tables known as "safest"  In this way, users can experiment,
and provide feedback on incremental improvements, while have a safe fallback.
>  # two applications hosted on the same cluster that can share a table, which has been
"aliased" into their namespace.  Namespace-local permissions are ignored, but a (most likely
read-only) view of the table is available.  This would be helpful for reference tables.
>  # quotas/priorities.  Implement namespace-specific priorities and resource allocations.
 It is reasonable to run namespace-specific queries and ingest on production equipment. Large
cluster resources are always limited, and often the *only* place where near-production quality
software can be run at full scale.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message