accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Thrift over SSL
Date Wed, 17 Jul 2013 17:03:04 GMT
I've been holding off making progress on that ticket, because it would
result in too many "svn mv" commands to preserve history. I was
waiting until we switched to git to make progress. Now that we have, I
plan on picking up where I left off, and working that, in conjunction
with ACCUMULO-210. I think some coordination would be helpful, but I
don't want to inhibit your progress.

Essentially, what I was going to do for ACCUMULO-756 was to create an
RPC maven module, with child modules for rpc-api, and rpc-thrift (a
concrete implementation), and was going to push all the thrift code
down to the rpc-thrift module. I was then hoping to specify the rpc
implementation either in configuration (accumulo-site.xml, for now) or
through auto-discovery of concrete implementations on the classpath,
so one could simply swap out implementation jars.

The way this might affect ACCUMULO-1009, depends on how you'd want to
do the implementation. You could simply add configuration to control
the provided thrift implementation to use SSL, or you could create a
separate pluggable implementation that extends the provided one, and
includes the necessary configuration. Another option is to make SSL a
more generic feature for all implementations, and move the
configuration switch up to the rpc-api module, so all other
implementations would have both an SSL and a non-SSL option. I haven't
played with SSL, or touched the RPC stuff in awhile, so I'm not sure
which option is best.

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


On Wed, Jul 17, 2013 at 12:36 PM, Michael Berman <mberman@sqrrl.com> wrote:
> Hi Devs,
> I'm starting work on enabling SSL encryption over the wire (ACCUMULO-1009).
> I noticed ACCUMULO-756 ("abstracting API communication mechanisms") is
> marked as in progress by Christopher.  Should I proceed with the SSL changes
> given today's thrift API code, or should I be trying to coordinate with the
> grander abstraction plan?  The entrypoint to my changes should be pretty
> focused...just a few lines of code around where we currently create thrift
> servers and clients.
>
> I'm also open to any other advice about how SSL should be integrated if
> others have particular requirements or solutions in mind.
>
> Thanks,
> Michael

Mime
View raw message