accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3147) Replication table should be user-controlled or live in accumulo namespace
Date Fri, 31 Oct 2014 20:23:35 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192410#comment-14192410
] 

Christopher Tubbs commented on ACCUMULO-3147:
---------------------------------------------

Oh, I see, this isn't like #3, then, if I understand you correctly.

You just want to be able to specify to use a different (user-created) table, by referencing
it in ZK (or some other config, but ZK makes sense), than the built-in table, after implementing
#1. That seems reasonable, but to be clear, the only context in which that is useful is if
somebody is using a pre-released verison of 1.7.0-SNAPSHOT (or a fork) before this change
and wants to continue using that table. That's fine with me, but it's not needed in Accumulo
upstream, and might be prone to removal in the future, since just looking at Accumulo internals,
it'd look just like an unnecessarily complex code path and ZK read. If that was the direction
this was going to go, I'd have preferred all the replication stuff sit outside Accumulo, as
an add-on, and just provide the internal hooks necessary for that external system to operate.
As is, it was designed baked-in, so such internals are likely going to be subject to change
in the future if you rely on them to support your use case (though, I assume you'd be on top
of watching for those changes that impact you if somebody proposes them).

So, yes, we can do the ZK solution as a workaround, but the other side of the issue is that
finding the table isn't the problematic part... all the problematic logic in the master and
in the tests that arbitrarily create/delete/scan/alter permissions on the replication table,
as if it was a user-managed table. That has to be cleaned up regardless of how the table is
found, which means that the ZK solution you propose really is only going to be useful for
you upgrading your existing instances, and not for anybody else to specify a different table
to manage replication.

> Replication table should be user-controlled or live in accumulo namespace
> -------------------------------------------------------------------------
>
>                 Key: ACCUMULO-3147
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3147
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: replication
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>            Priority: Blocker
>             Fix For: 1.7.0
>
>
> At present, it looks like the replication table is managed by/written to by the system
user, yet the table lives in the default namespace, which is where user tables live.
> This appears to violate the namespace model of segregating system tables from user tables.
> There's a few options for resolution:
> # Move the replication table into the reserved accumulo system namespace (there's some
complication with this, because the system namespace is currently static, and the replication
table may be created at any time; additionally, if users are expected to interact with this
table... and I'm not sure if they are at all, the system namespace is probably not appropriate).
> # Create an additional reserved system namespace for replication (my least preferred
option).
> # Use user credentials to manage/write to this table, rather than the system user (this
is what the tracer/trace table does, and this is my preferred solution.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message