[
https://issues.apache.org/jira/browse/ACCUMULO-3839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554733#comment-14554733
]
Josh Elser commented on ACCUMULO-3839:
--------------------------------------
bq. Not sure if you even need to call add volumes in this case. Add volumes
just initializes the dir with instance id, but thats already done for that dir
Yes, we did come to that conclusion.
bq. Not sure exactly what the intent of that check is
My hunch was that it meant to make sure you don't re-introduce a volume that
you're trying to replace? On second thought, it could have also meant to ensure
that the replacement exists in instance.volumes (and the condition was just
reversed).
> Nonsense error when configuring instance.volumes.replacements
> -------------------------------------------------------------
>
> Key: ACCUMULO-3839
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3839
> Project: Accumulo
> Issue Type: Bug
> Affects Versions: 1.7.0
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Critical
> Fix For: 1.6.3, 1.8.0, 1.7.1
>
> Attachments:
> 0001-ACCUMULO-3839-Perform-sanity-check-on-the-proper-rep.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [~billie.rinaldi] was working with me, trying to configure an existing 1.7.0
> instance to start working with HDFS HA.
> Take the following:
> {noformat}
> instance.volumes=hdfs://nn1:port/accumulo
> {noformat}
> and then move to
> {noformat}
> instance.volumes=hdfs://nameservice/accumulo
> instance.volumes.replacements=hdfs://nn1:port/accumulo
> hdfs://nameservice/accumulo
> {noformat}
> While this is the correct configuration, {{accumulo init --add-volumes}}
> spews this error
> {noformat}
> hdfs://nameservice/accumulo is set to be replaced in
> instance.volumes.replacements and should not appear in instance.volumes. It
> is highly recommended that this property be removed as data could still be
> written to this volume.
> {noformat}
> It looks like this check that was added in ACCUMULO-2793 incorrectly compares
> the wrong element in the replacement pairs. It's reasonable to assume that
> the check was _meant_ to verify that we don't try to write more data to a
> volume that is intended to be replaced.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
