[
https://issues.apache.org/jira/browse/ACCUMULO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799449#comment-13799449
]
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: 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, 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 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 was sent by Atlassian JIRA
(v6.1#6144)
