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