accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vines (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-802) table namespaces
Date Fri, 18 Oct 2013 19:51:41 GMT


John Vines commented on ACCUMULO-802:

bq. I wasn't sure whether I should change the TableOperations functions to throw TableNamespaceNotFoundExceptions
(and possibly break backwards compatibility), so right now they throw IllegalArgumentExceptions
constructed from TableNamespaceNotFoundExceptions.
I think making a TableNamespaceNotFoundException as an extension of TableNotFoundException
should be sufficient?

bq. In copying the format of TableOperations' create() function, I made the TableNamespaceOperations()
create function take a TimeType for input, but I don't use it. I wasn't sure if we should
apply that TimeType to all tables in the namespace or scrap that functionality for namespaces
in general.
I am under the impression that there is another layer of configuration hierarchy of table
configurations with the namespaces. And with that, TimeType is one. So having a alternative
default TimeType for a namespace makes sense. However, if there is not a configuration hierarchy,
then there should be no TimeType involved.

bq. I never looked into putting qoutas/priorities on namespaces, although that was one of
the original use cases.
We can defer this to 1.7+ as it's a nice to have, not a bare minimum for namepsace implementation

bq. I never implemented "aliasing" or having one table show in multiple namespaces.
Also defer, not a necessity

bq. I never messed with the Monitor code to organize the tables by namespace (ACCUMULO-1480).
Defer, !necessity

bq. I changed the default initial table properties (that are applied when a table is created)
to instead be applied to new namespaces (and the default namespace) rather than each table.
Makes sense

bq. I wasn't sure if there should be any initial properties on the system namespace, so I
left it empty (no default properties).
Not quite sure what this means

bq. I didn't add default user permissions for a namespaces (ACCUMULO-617 and ACCUMULO-1479).
I sorta think this should be there, as it would cause a lot of issues to add down the line.

bq. While running RandomWalk, one related error that I see every once in a while is that a
table will have a reference to a namespace that no longer exists. (There are a few other errors
that seem unrelated to table namespaces).
Probably has to do with ZK cache timings. May have to add some wait time in the test to allow
propagation. Propagation time is something that should be expected with this behavior.

> 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, ACCUMULO-802.v4.patch, ACCUMULO-802.v5.patch, table-namespaces-README.txt,
table-namespaces-README.v1.txt, table-namespaces-README.v2.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 was sent by Atlassian JIRA

View raw message