accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Removing relative paths from metadata
Date Tue, 22 Jul 2014 21:04:25 GMT
On Tue, Jul 22, 2014 at 4:54 PM, Christopher <ctubbsii@apache.org> wrote:

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

I am not a fan either.  The concern that made me think of that possibility
was that the user may want to ensure the config for resolving relative
paths was correct before proceeding.


> 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