Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAA+ACqc-Wzav1nj=z_6-NV+6u98-8kt9uqNUUDHC29YDkHFPXg@mail.gmail.com>
References: 
 <CAL5zq9beQf0ppGSJRB=iike=N8dMxEQyfkb52eUVtX0qOoPCCw@mail.gmail.com>
	<1375389221800.35c4f76e@Nodemailer>
	<CAL5zq9YcqGcM42WKX+j5S+WSx2i=G+CF-+NQrpJ3CCFfH6GK9g@mail.gmail.com>
	<CAA+ACqc-Wzav1nj=z_6-NV+6u98-8kt9uqNUUDHC29YDkHFPXg@mail.gmail.com>
Date: Fri, 2 Aug 2013 13:20:16 -0400
Message-ID: 
 <CAL5zq9b2LUU-y_gCNBArdfF_EqmfUHTiUe_7QCtVhuzWCPCaPA@mail.gmail.com>
Subject: Re: client config files
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yes, I think that would be provide the best user experience for client
code. I'm not too stuck on this point, though I do think it should be
independent of AccumuloConfiguration for reasons I mentioned on
ACCUMULO-1397.

I've been playing with the idea of creating a generic typed
configuration library that extends commons-configuration to make it
easier to get the same value as AccumuloConfiguration's Property
enums, but without being so monolithic and Accumulo server-specific.
That common interface could form the basis of an
AccumuloClientConfiguration, and independently, an
AccumuloServerConfiguration. Do you think that would be useful for
your client configuration?

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


On Fri, Aug 2, 2013 at 10:11 AM, Michael Berman <mberman@sqrrl.com> wrote:
> So does this mean you'd rather have the config switches be called somethi=
ng
> like javax.net.ssl.trustStore rather than general.server.ssl.trustStore i=
n
> the Accumulo Properties?  Our implementation of SSL will be provided by t=
he
> thrift connectors rather than us using JSSE directly, so we'll have to
> interpret them ourselves rather than JSSE doing it automatically.  Should
> we respect these flags if they're passed in through System.getProperties(=
)
> in addition to whatever the normal config flow ends up being?  Note that =
we
> won't be able to respect many of the flags, since we're at Thrift's mercy
> for socket construction.
>
>
> On Thu, Aug 1, 2013 at 10:06 PM, Christopher <ctubbsii@apache.org> wrote:
>
>> I'm generally not a fan of the way some standard Java things have been
>> reinvented in Hadoop. I've always seen JSSE SSL config as system
>> properties, optionally stored in a properties file. Even if Hadoop is
>> using an XML-based configuration for this purpose, I'd still steer
>> clear of it, for this reason.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Thu, Aug 1, 2013 at 4:33 PM, Joey Echeverria <joey@cloudera.com> wrot=
e:
>> > I generally prefer properties files to XML, but there may be a argumen=
t
>> for reusing Hadoop's SSL configuration system which is XML based.
>> >
>> >
>> > -Joey
>> > =97
>> > Sent from Mailbox for iPhone
>> >
>> > On Thu, Aug 1, 2013 at 3:08 PM, Christopher <ctubbsii@apache.org> wrot=
e:
>> >
>> >> ^ Another reason I like commons-configuration here is for
>> >> property-interpolation with HierarchicalConfiguration.
>> >> --
>> >> Christopher L Tubbs II
>> >> http://gravatar.com/ctubbsii
>> >> On Thu, Aug 1, 2013 at 3:07 PM, Christopher <ctubbsii@apache.org>
>> wrote:
>> >>> I absolutely DO think they should be combined in a properties file
>> >>> located in $HOME/.accumulo/config
>> >>> I absolutely DO NOT think this client configuration should be
>> >>> exclusive to the shell, and I absolutely DO NOT think it should be
>> >>> XML.
>> >>>
>> >>> I would love to see all our clients/client code use
>> >>> commons-configuration to hold properties from the properties file, s=
o
>> >>> that only a --config parameter is needed (with reasonable defaults, =
so
>> >>> even that is not absolutely necessary). I also think that every
>> >>> property that can exist in the file should be possible to override o=
n
>> >>> the command-line. I personally prefer to use system properties, usin=
g
>> >>> commons-configuration's HierarchicalConfiguration, but jcommander ma=
y
>> >>> make it easier to do the same thing in a slightly different way.
>> >>>
>> >>> --
>> >>> Christopher L Tubbs II
>> >>> http://gravatar.com/ctubbsii
>> >>>
>> >>>
>> >>> On Thu, Aug 1, 2013 at 12:25 PM, Michael Berman <mberman@sqrrl.com>
>> wrote:
>> >>>> As part of SSL, we need to introduce configuration so accumulo clie=
nts
>> >>>> (such as ZooKeeperInstance) can find trust stores.  It seems like
>> this has
>> >>>> a lot in common with shell config files in ACCUMULO-1397.  Do peopl=
e
>> think
>> >>>> these should be combined, or should the shell have its own separate
>> config?
>> >>>>  I was imagining a simple java .properties-style key=3Dvalue list.
>>  Does this
>> >>>> seem reasonable?  Or should the format be more like the xml of the
>> site
>> >>>> config?  I was also imagining looking through a list of files that
>> would
>> >>>> each override settings, perhaps in the following order (from lowest=
 to
>> >>>> highest priority):
>> >>>>
>> >>>> /etc/accumulo/client.conf
>> >>>> $ACCUMULO_HOME/conf/client.conf
>> >>>> $HOME/.accumulo/config
>> >>>> --client-config command line switch for shell or explicit parameter
>> passed
>> >>>> to ZooKeeperInstance
>> >>>>
>> >>>> Does this sound good to y'all?  Should the explicit switch/paramete=
r
>> have
>> >>>> per-property override semantics, or should it just be used as the
>> exclusive
>> >>>> source of properties if specified?
>> >>>>
>> >>>> Mike Drob, are you actively working on the shell side of this
>> already?  I
>> >>>> see that bug is assigned to you...
>> >>>>
>> >>>> Thanks,
>> >>>> Michael
>>