So does this mean you'd rather have the config switches be called something
like javax.net.ssl.trustStore rather than general.server.ssl.trustStore in
the Accumulo Properties? Our implementation of SSL will be provided by the
thrift connectors rather than us using JSSE directly, so we'll have to
Yeah, I was starting to think along those lines in ACCUMULO-1397 (a generic
configuration library). Although options about how to make connections to
accumulo are needed by both clients and accumulo services themselves (for
masters talking to tablets, for example).
On Fri, Aug 2, 2013 at 1:20
Sorry for the delay, it's been one of those weeks.
The current version would probably not be backwards compatible to
0.20.2 just based on changes in dependencies. We're looking right now
to see how hard it is to have three way compatibility (0.20, 1.0,
2.0).
-Joey
On Thu, Aug 1, 2013 at 7:33
On Thu, Aug 1, 2013 at 4:33 PM, Joey Echeverria j...@cloudera.com wrote:
I generally prefer properties files to XML, but there may be a argument
for reusing Hadoop's SSL configuration system which is XML based.
I also prefer prefer properties files over XML. The only reason I can
think that
The overlap is only a conceptual overlap, not an implementation one.
Servers use HdfsZooInstance, which reads the xml configuration file,
and read the instanceId out of HDFS. Clients have ZooKeeperInstance,
which requires user input and gets the instanceId from an a convenient
pointer in ZK. Even
Yeah, I agree. Consistency with Hadoop here is probably not that valuable.
-Joey
On Fri, Aug 2, 2013 at 2:28 PM, Keith Turner ke...@deenlo.com wrote:
On Thu, Aug 1, 2013 at 4:33 PM, Joey Echeverria j...@cloudera.com wrote:
I generally prefer properties files to XML, but there may be a
Would it be reasonable to consider a version of 1.4 that breaks
compatibility with 0.20? I'm not really a fan of this, personally, but
am curious what others think.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Fri, Aug 2, 2013 at 2:22 PM, Joey Echeverria j...@cloudera.com wrote:
I don't think that's a good idea unless you can come up with very
clear version number change.
-Joey
On Fri, Aug 2, 2013 at 2:31 PM, Christopher ctubb...@apache.org wrote:
Would it be reasonable to consider a version of 1.4 that breaks
compatibility with 0.20? I'm not really a fan of this,
I believe it is an implementation overlap. Both ZKInstance and the
master-tablet thrift connections get created in ThriftUtil.getClient().
Higher up in the stack, in both paths, we have access to an Instance from
which to draw configuration (with getConfiguration()). In one case, it's a
Which version of 0.20 are you testing against? Vanilla, or cdh3 flavored?
On Fri, Aug 2, 2013 at 2:37 PM, Joey Echeverria j...@cloudera.com wrote:
I don't think that's a good idea unless you can come up with very
clear version number change.
-Joey
On Fri, Aug 2, 2013 at 2:31 PM,
Okay, so there is implementation overlap, but that overlap is pretty
minimal (admittedly, it could potentially grow). The only thing it is
currently used for, is to carry the value of the RPC timeout, and this
is not currently very friendly to end users (they'd have to
instantiate something that
11 matches
Mail list logo
