On Tue, Jul 22, 2014 at 4:54 PM, Christopher <[email protected]> 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 <[email protected]> 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? > > >
