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 55830182A4 for ; Wed, 1 Jul 2015 03:01:54 +0000 (UTC) Received: (qmail 52478 invoked by uid 500); 1 Jul 2015 03:01:49 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 52426 invoked by uid 500); 1 Jul 2015 03:01:48 -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 52417 invoked by uid 99); 1 Jul 2015 03:01:48 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jul 2015 03:01:48 +0000 Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 91A811A0255 for ; Wed, 1 Jul 2015 03:01:48 +0000 (UTC) Received: by ykdr198 with SMTP id r198so27420715ykd.3 for ; Tue, 30 Jun 2015 20:01:47 -0700 (PDT) X-Received: by 10.129.123.196 with SMTP id w187mr28024425ywc.100.1435719707899; Tue, 30 Jun 2015 20:01:47 -0700 (PDT) MIME-Version: 1.0 References: <5593281F.3090708@jhu.edu> <55932F24.7030707@gmail.com> <55933D18.5090509@jhu.edu> In-Reply-To: <55933D18.5090509@jhu.edu> From: Christopher Date: Wed, 01 Jul 2015 03:01:38 +0000 Message-ID: Subject: Re: client.conf warning in 1.7.0 To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=001a114941522fbf190519c78bfd --001a114941522fbf190519c78bfd Content-Type: text/plain; charset=UTF-8 That's correct. And, that's precisely the kind of things it'd be nice to add. I would say that it's on the agenda. On Tue, Jun 30, 2015, 21:08 Max Thomas wrote: > Christopher/Josh - thanks for the quick responses. > > I certainly understand the concerns about passing around > accumulo-site.xml. While I haven't had any issues with this, based on > poking around ClientConfiguration.java it seems that it was necessary > for various SSL/Kerberos features. > > Forgive what might be a very naive question, but: currently, as a > consumer of an Accumulo from Java, I've got to provide (minimally) a > username, password, instance name, and zookeeper server string. Based on > a brief scan of ClientConfiguration, though, it does not seem that the > username/password will be read from client.conf - is that correct? Will > support for that be added in the future? > > On 6/30/15 8:07 PM, Josh Elser wrote: > > I'll open up a documentation ticket. I thought we had something in there > > but maybe not. > > > > For a normal instance, this file would likely just contain > > > > instance.zookeeper.host=zkserver1,zkserver2,etc.. > > > > Like Christopher says, it's not required yet, but it would be a good > > habit to start using it as it's the direction we're heading. > > > > Christopher wrote: > >> In short, yes, it will likely be required for clients in the future > >> (if you want something other than the defaults). > >> > >> The longer answer is that we just wanted to make sure the user > >> understood where their configuration is coming from, in case things > >> aren't working as they expect. > >> > >> We've been moving towards separating the server-side configuration > >> (mostly, accumulo-site.xml) from client utilities, due to the fact > >> that a client cannot be expected to have access to the > >> accumulo-site.xml (it contains a sensitive instance.secret and other > >> stuff a client doesn't need), and it can be confusing to have a > >> client-specific "accumulo-site.xml", which is not the server's > >> "accumulo-site.xml". > >> > >> If you don't have this file, it will fall back to reasonable defaults > >> (reading "accumulo-site.xml" from the classpath, if one is available). > >> > >> Some of this behavior is a bit screwy, but we've been careful to > >> preserve backwards compatibility as much as possible. In the future, > >> it is my intention (and perhaps others share this goal with me) to > >> clean up these configs quite a bit. So, if you have any suggestions on > >> how you think things should work, feedback is always welcome. > >> > >> -- > >> Christopher L Tubbs II > >> http://gravatar.com/ctubbsii > >> > >> > >> On Tue, Jun 30, 2015 at 7:37 PM, Max Thomas wrote: > >>> When running code against a 1.7.0 cluster, the following warning keeps > >>> appearing: > >>> > >>> 2015-06-30 19:32:58,352 WARN o.a.a.c.c.ClientConfiguration [main] > >>> Found no > >>> client.conf in default paths. Using default client configuration > values. > >>> > >>> The only mention of this file that I can find, however, is in the > manual > >>> buried in a section on Kerberos. > >>> > >>> Is this a warning because this will be required for clients in the > >>> future? > --001a114941522fbf190519c78bfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's correct. And, that's precisely the kind of th= ings it'd be nice to add. I would say that it's on the agenda.


On Tue, Jun 30, 2015, 21:08= =C2=A0Max Thomas <max.thomas@jhu.e= du> wrote:
Christopher/Josh = - thanks for the quick responses.

I certainly understand the concerns about passing around
accumulo-site.xml. While I haven't had any issues with this, based on poking around ClientConfiguration.java it seems that it was necessary
for various SSL/Kerberos features.

Forgive what might be a very naive question, but: currently, as a
consumer of an Accumulo from Java, I've got to provide (minimally) a username, password, instance name, and zookeeper server string. Based on a brief scan of ClientConfiguration, though, it does not seem that the
username/password will be read from client.conf - is that correct? Will
support for that be added in the future?

On 6/30/15 8:07 PM, Josh Elser wrote:
> I'll open up a documentation ticket. I thought we had something in= there
> but maybe not.
>
> For a normal instance, this file would likely just contain
>
> instance.zookeeper.host=3Dzkserver1,zkserver2,etc..
>
> Like Christopher says, it's not required yet, but it would be a go= od
> habit to start using it as it's the direction we're heading. >
> Christopher wrote:
>> In short, yes, it will likely be required for clients in the futur= e
>> (if you want something other than the defaults).
>>
>> The longer answer is that we just wanted to make sure the user
>> understood where their configuration is coming from, in case thing= s
>> aren't working as they expect.
>>
>> We've been moving towards separating the server-side configura= tion
>> (mostly, accumulo-site.xml) from client utilities, due to the fact=
>> that a client cannot be expected to have access to the
>> accumulo-site.xml (it contains a sensitive instance.secret and oth= er
>> stuff a client doesn't need), and it can be confusing to have = a
>> client-specific "accumulo-site.xml", which is not the se= rver's
>> "accumulo-site.xml".
>>
>> If you don't have this file, it will fall back to reasonable d= efaults
>> (reading "accumulo-site.xml" from the classpath, if one = is available).
>>
>> Some of this behavior is a bit screwy, but we've been careful = to
>> preserve backwards compatibility as much as possible. In the futur= e,
>> it is my intention (and perhaps others share this goal with me) to=
>> clean up these configs quite a bit. So, if you have any suggestion= s on
>> how you think things should work, feedback is always welcome.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Tue, Jun 30, 2015 at 7:37 PM, Max Thomas<max.thomas@jhu.edu>=C2=A0 wrote= :
>>> When running code against a 1.7.0 cluster, the following warni= ng keeps
>>> appearing:
>>>
>>> 2015-06-30 19:32:58,352 WARN=C2=A0 o.a.a.c.c.ClientConfigurati= on [main]
>>> Found no
>>> client.conf in default paths. Using default client configurati= on values.
>>>
>>> The only mention of this file that I can find, however, is in = the manual
>>> buried in a section on Kerberos.
>>>
>>> Is this a warning because this will be required for clients in= the
>>> future?
--001a114941522fbf190519c78bfd--