Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of dlmarion@comcast.net
 designates 96.114.154.160 as permitted sender)
Date: Thu, 11 Dec 2014 13:15:36 +0000 (UTC)
From: dlmarion@comcast.net
To: dev@accumulo.apache.org
Message-ID: <999388760.2391882.1418303736974.JavaMail.zimbra@comcast.net>
In-Reply-To: 
 <CAL5zq9aYHMwFwF9XcrwiBs65KtoHpM8hgbzpuqVNG10UoUBX4g@mail.gmail.com>
References: <qhp6c85n4l15wip8m697bj2k.1418267001999@email.android.com>
 <CAL5zq9aYHMwFwF9XcrwiBs65KtoHpM8hgbzpuqVNG10UoUBX4g@mail.gmail.com>
Subject: Re: Planning for (eventual) removal of instance.dfs.{uri,dir}
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2391881_1081648.1418303736973"
Thread-Topic: Planning for (eventual) removal of instance.dfs.{uri,dir}
Thread-Index: kT9EJKKJkHK7v8We0GeMAVQEQlTOPA==

------=_Part_2391881_1081648.1418303736973
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

How so? If someone upgrades from another version and is using a different dir, doesn't specify it in the configuration, and we assume /accumulo, then their database won't start. The other option, which may be safer than making any assumptions, is to make instance.volumes a required parameter with no defaults. 

----- Original Message -----

From: "Christopher" <ctubbsii@apache.org> 
To: "Accumulo Dev List" <dev@accumulo.apache.org> 
Sent: Wednesday, December 10, 2014 11:51:39 PM 
Subject: Re: Planning for (eventual) removal of instance.dfs.{uri,dir} 

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


------=_Part_2391881_1081648.1418303736973--