accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-3570) Relax restriction on instance.volumes.replacements so new volume does not have to be in instance.volumes
Date Mon, 06 Apr 2015 02:53:13 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Josh Elser updated ACCUMULO-3570:
---------------------------------
    Fix Version/s:     (was: 1.7.0)
                   1.7.1
                   1.8.0

> Relax restriction on instance.volumes.replacements so new volume does not have to be
in instance.volumes
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-3570
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3570
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.6.1
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>             Fix For: 1.6.3, 1.8.0, 1.7.1
>
>
> ACCUMULO-1832 added the ability to replace volume references with a differently named
volume.
> However, it also added a restriction that the new volume must be specified in the {{instance.volumes}}
set. While that is a use case, it is an unnecessary restriction and conflates the purpose
of replacements with regular volumes. {{instance.volumes}} is the set of volumes to write
new tablets files to, while the replacements are intended to assign in remapping references
to already written data, so it can be read.
> One use case that this restriction prevents, for example, is migrating from failing hardware
to a new cluster. A user may rename the old namenode from "nn" to "nn-old", and name the new
one "nn-new", but wouldn't want new files to be written to "nn-old". This could be achieved
by a custom volume chooser which blacklists "nn-old" for new tablets, but that would require
writing custom code. Relaxing this restriction allows users to get the same behavior in configuration.



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

Mime
View raw message