[
https://issues.apache.org/jira/browse/ACCUMULO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 comment)
# 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: https://issues.apache.org/jira/browse/ACCUMULO-802
> 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 delegated.
> # 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: http://www.atlassian.com/software/jira
