Return-Path: 
 <dev-return-11794-apmail-accumulo-dev-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-dev-archive@www.apache.org
Delivered-To: apmail-accumulo-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id DAD9010F68
	for <apmail-accumulo-dev-archive@www.apache.org>;
 Thu, 11 Dec 2014 04:51:40 +0000 (UTC)
Received: (qmail 69542 invoked by uid 500); 11 Dec 2014 04:51:40 -0000
Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org
Received: (qmail 69494 invoked by uid 500); 11 Dec 2014 04:51:40 -0000
Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@accumulo.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@accumulo.apache.org>
List-Post: <mailto:dev@accumulo.apache.org>
List-Id: <dev.accumulo.apache.org>
Reply-To: dev@accumulo.apache.org
Delivered-To: mailing list dev@accumulo.apache.org
Received: (qmail 69482 invoked by uid 99); 11 Dec 2014 04:51:40 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org)
 (140.211.11.15)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Dec 2014 04:51:40 +0000
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com
 [209.85.223.172])
	by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with
 ESMTPSA id 5C8361A025F
	for <dev@accumulo.apache.org>; Thu, 11 Dec 2014 04:51:40 +0000 (UTC)
Received: by mail-ie0-f172.google.com with SMTP id tr6so4175528ieb.3
        for <dev@accumulo.apache.org>; Wed, 10 Dec 2014 20:51:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.16.41 with SMTP id y41mr7993608ioi.41.1418273499863;
 Wed, 10 Dec 2014 20:51:39 -0800 (PST)
Received: by 10.64.159.130 with HTTP; Wed, 10 Dec 2014 20:51:39 -0800 (PST)
In-Reply-To: <qhp6c85n4l15wip8m697bj2k.1418267001999@email.android.com>
References: <qhp6c85n4l15wip8m697bj2k.1418267001999@email.android.com>
Date: Wed, 10 Dec 2014 23:51:39 -0500
Message-ID: 
 <CAL5zq9aYHMwFwF9XcrwiBs65KtoHpM8hgbzpuqVNG10UoUBX4g@mail.gmail.com>
Subject: Re: Planning for (eventual) removal of instance.dfs.{uri,dir}
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a113f1d282763ee0509e988f0

--001a113f1d282763ee0509e988f0
Content-Type: text/plain; charset=UTF-8

The URI is probably reasonable, but the dir is potentially problematic if
you weren't using the default.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Wed, Dec 10, 2014 at 10:03 PM, dlmarion <dlmarion@comcast.net> wrote:

> Looks like VolumeConfiguration falls back to fs.defaultFS for the uri and
> /accumulo for the dir. You could remove both properties and still keep this
> as the documented default behavior if instance.volumes is not specified.
>
>
>
> <div>-------- Original message --------</div><div>From: Christopher <
> ctubbsii@apache.org> </div><div>Date:12/10/2014  9:13 PM  (GMT-05:00)
> </div><div>To: Accumulo Dev List <dev@accumulo.apache.org>
> </div><div>Cc:  </div><div>Subject: Re: Planning for (eventual) removal of
> instance.dfs.{uri,dir} </div><div>
> </div>My ACCUMULO-2589 branch in github (
> https://github.com/ctubbsii/accumulo/tree/ACCUMULO-2589) does have a
> commit
> that drops a bunch of stuff (which may or may not be accepted as is for
> 2.0). The instance.dfs.{uri,dir} properties aren't so easy and require more
> planning, because it's not just removing a property... it's also dealing
> with updating internal data by making relative paths absolute.
>
> For what it's worth, I'm also looking at what changes if we drop Hadoop 1
> support.
>
> As for the validation of config, I think we do a sanity check on startup
> already, which we can always extend. Doesn't solve this issue, though.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Dec 10, 2014 at 8:59 PM, dlmarion <dlmarion@comcast.net> wrote:
>
> > We should schedule a bunch of deprecated things for removal in 2.0 to
> ease
> > maintenance. Do we have a way to validate the site.xml and zookeeper
> > settings before startup and fail with appropriate error message.
> >
> >
> >
> > <div>-------- Original message --------</div><div>From: Christopher <
> > ctubbsii@apache.org> </div><div>Date:12/10/2014  8:44 PM  (GMT-05:00)
> > </div><div>To: Accumulo Dev List <dev@accumulo.apache.org>
> > </div><div>Cc:  </div><div>Subject: Planning for (eventual) removal of
> > instance.dfs.{uri,dir} </div><div>
> > </div>So,
> >
> > instance.volumes replaces instance.dfs.uri and instance.dfs.dir in 1.6.
> > But, what's our long-term plan for these? I ask, because we still have
> > internal code that uses instance.dfs.uri to resolve relative paths.
> >
> > Should we force these to be re-written at some point (maybe on upgrade to
> > 1.7)? Should we continue to support the deprecated properties
> indefinitely
> > and continue the lazy re-write-on-compact? Do we transition by requiring
> > instance.volumes to specify the volumes, and only use the old properties
> to
> > resolve relative paths?
> >
> > My personal view is that we should provide an upgrade-prep/check tool
> prior
> > to upgrade to 2.0, which checks and/or re-writes paths and verifies that
> > instance.volumes is set.
> >
> > Does anybody have a different opinion on this?
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>

--001a113f1d282763ee0509e988f0--