[
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)
