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 21:14:31 GMT
On Tue, Jul 22, 2014 at 5:04 PM, Keith Turner <keith@deenlo.com> wrote:

> 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.
>
>
>
Good point, but a separate utility might serve that better. On the other
hand, it had better already be correct if they're already running 1.6.x ...


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