Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D7F7711B4A for ; Mon, 16 Jun 2014 21:43:13 +0000 (UTC) Received: (qmail 44882 invoked by uid 500); 16 Jun 2014 21:43:08 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 44830 invoked by uid 500); 16 Jun 2014 21:43:08 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 44819 invoked by uid 99); 16 Jun 2014 21:43:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2014 21:43:08 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of busbey@cloudera.com designates 209.85.216.51 as permitted sender) Received: from [209.85.216.51] (HELO mail-qa0-f51.google.com) (209.85.216.51) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jun 2014 21:43:06 +0000 Received: by mail-qa0-f51.google.com with SMTP id j7so6904067qaq.24 for ; Mon, 16 Jun 2014 14:42:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=0rTMYk+Lc7NI+PvqLdImF5ILvLpPBXFycdsLpq7L604=; b=BwGt2M8pjAGuptao5jlbUwWJ+X6eOUFg0xRVLHc3Ph378o+bwrwbC5SIokH6BXkE/K 84iF5UiCtSA19MiVUZnw2Dq7toolFPt3ek2wg9wutN7M0weCx7rwPTAuo9ZQdl3dKAz5 tmvUqu5nZRmUEFUo2Xg2dEnOfAVSIlNHULBbsaJB9edANZthObThkpW42ArEHa2shy0M GULUVWcLLAjfBIgq/7K3ZDtyAXrWwazq9tynwYdzavolUGYsWYPLgcx+pgdcdnZSiPA0 iTDlQjVPysMwPD4pLg2r7EjvMWSf2O8adkzGecFdmVl+5aOE5UInb/aYvI/wS1jjpTBx 2C4A== X-Gm-Message-State: ALoCoQnRhq41m65/g/cUqThemvf6HuOtrWkANPxdeyOedsDOeJL3CohZ2l82sf/Wb03wDWD4qcZF X-Received: by 10.140.95.105 with SMTP id h96mr28677229qge.2.1402954962084; Mon, 16 Jun 2014 14:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.64.72 with HTTP; Mon, 16 Jun 2014 14:42:22 -0700 (PDT) In-Reply-To: References: From: Sean Busbey Date: Mon, 16 Jun 2014 17:42:22 -0400 Message-ID: Subject: Re: [DISCUSS] Should we support upgrading 1.4 -> 1.6 w/o going through 1.5? To: Accumulo User List , "dev@accumulo apache. org" Content-Type: multipart/alternative; boundary=001a11c15ece26b8c404fbfae8bb X-Virus-Checked: Checked by ClamAV on apache.org --001a11c15ece26b8c404fbfae8bb Content-Type: text/plain; charset=UTF-8 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 < wilhelm.von.cloud@accumulo.net> 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 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 --001a11c15ece26b8c404fbfae8bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unfortunately, the way we do updates to the metadata table= makes a standalone utility problematic.

The current imp= lementation relies on the LocalWALRecovery utility to handle the "move= files to HDFS" step and then does the metadata / zk updates in the ma= ster start up the same way we do for other existing upgrade steps.

-Sean


On Mon, Jun 16, 2014 at 5:31 PM, William Slacum <wilhelm.von.cloud@accumulo.net> wrote:
How much of this is a stand= alone utility? I think a magic button approach would be good for this case.=


On Mon, Jun 16, 2014 at 5:24 PM, Sean Busbey <busbey@cloudera.com= > wrote:
In an effort to get more users off of our now unsupported 1.4 release, sh= ould we support upgrading directly to 1.6 without going through a 1.5 upgra= de?

More directly for those on user@: would you be more likely t= o 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 o= ur 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 compli= cated. 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, a= nything 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
--001a11c15ece26b8c404fbfae8bb--