Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGUtCHrG+a=JtYZyFZE-txpAHeNiBy+zbmc1fMTmcqkuJF6osA@mail.gmail.com>
References: 
 <CAGUtCHrG+a=JtYZyFZE-txpAHeNiBy+zbmc1fMTmcqkuJF6osA@mail.gmail.com>
Date: Tue, 22 Jul 2014 16:54:09 -0400
Message-ID: 
 <CAL5zq9Z2H1fCyM2nsDC36xCjjkeHp0-qUOvv4f9omB7A09KzFA@mail.gmail.com>
Subject: Re: [DISCUSS] Removing relative paths from metadata
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11345702db68f204fece6c96

--001a11345702db68f204fece6c96
Content-Type: text/plain; charset=UTF-8

I'd personally like to have instance.dfs.uri and instance.dfs.dir gone as
soon as possible (1.7.0 and later), and I wouldn't want to keep around code
that continues to work with relative paths at all, so given the two
options, a utility seems the better of the two, because the only code that
deals with them would be inside the utility.

Some of us were in favor of automatically re-writing all relative paths
during the upgrade to 1.6.0, so that once it was fully up and running, all
relative paths would be gone. So, I would not be opposed to automatically
doing that in a future 1.6.x upgrade. I'm not a fan of the boolean config,
because I think it should be transparent to the user and there's not really
a need to expose internal metadata details to users. However, even if we
went with this route, we'd still want to support a direct upgrade from
1.6.0 (and any other 1.6.x version that didn't force absolute paths), so a
utility would still be needed.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Tue, Jul 22, 2014 at 12:51 PM, Keith Turner <keith@deenlo.com> wrote:

> Had some discussion w/ Dave Marion about the need to drop relatavie paths
> from internal metadata.  From a user standpoint the requirement to possibly
> configure instance.dfs.uri and instance.dfs.dir if they might have relative
> paths is confusing over the long term.  Also it places more of a
> maintenance burden on us if we need to ensure all bug fixes and new
> features work properly w/ relative paths.
>
> What are our options and what should the timeline be?  We could require the
> user to do something to remove all relative paths before before starting
> 1.7.0 for example.
>
> Some of the things we discussed
>
>  * Provide a utility to rewrite all relative paths
>  * Rework the volume replacement code to work w/ relative paths
>
> A stand alone utility is tricky.  Don't want to modify tablet metadata if
> the table is loaded.  Thats why the volume replacement code has the tablets
> themselves do the replacement.
>
> I like the idea of reworking the volume replacement code, but I do not like
> the idea of it happening automatically (like the first time 1.6.2 is
> started).   Could possibly have a boolean config
> instance.volume.replaceRelative.  When this is set, as tablets are loaded
> and when the GC starts relative paths would be replaced using current
> instance.dfs.* config or hdfs config.
>
> Still uncertain about the best solution.  Looking for the course of least
> user confusion and least maintenance.  I think
> instance.volume.replaceRelative is a bit confusing from a user perspective.
>
> What other options are there to solve this problem?  Any issue w/ the
> premise?
>

--001a11345702db68f204fece6c96--