Unfortunately, the way we do updates to the metadata table makes a standalone utility problematic.
The current implementation relies on the LocalWALRecovery utility to handle the "move files to HDFS" step and then does the metadata / zk updates in the master start up the same way we do for other existing upgrade steps. -Sean On Mon, Jun 16, 2014 at 5:31 PM, William Slacum < [email protected]> wrote: > How much of this is a standalone utility? I think a magic button approach > would be good for this case. > > > On Mon, Jun 16, 2014 at 5:24 PM, Sean Busbey <[email protected]> wrote: > >> In an effort to get more users off of our now unsupported 1.4 release, >> should we support upgrading directly to 1.6 without going through a 1.5 >> upgrade? >> >> More directly for those on user@: would you be more likely to upgrade >> off of 1.4 if you could do so directly to 1.6? >> >> We have this working locally at Cloudera as a part of our CDH integration >> (we shipped 1.4 and we're planning to ship 1.6 next). >> >> We can get into implementation details on a jira if there's positive >> consensus, but the changes weren't very complicated. They're mostly >> >> * forward porting and consolidating some upgrade code >> * additions to the README for instructions >> >> Personally, I can see the both sides of the argument. On the plus side, >> anything to get more users off of 1.4 is a good thing. On the negative >> side, it means we have the 1.4 related upgrade code sitting in a supported >> code branch longer. >> >> Thoughts? >> >> -- >> Sean >> > > -- Sean
