accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Removing relative paths from metadata
Date Tue, 22 Jul 2014 20:54:09 GMT
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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message