accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3839) Nonsense error when configuring instance.volumes.replacements
Date Thu, 21 May 2015 17:52:17 GMT


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:
>             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

View raw message