Is "the code being 'at rest'" you making a funny about active development?
Making sure I haven't lost my ability to get jokes :)

I see two reasons why the code would be inactive: the feature is good
enough as is or it's not interesting enough to attract attention.
Considering it's not public API, there are no discussions to bring into the
public API, and there's no effort to document how to use it, my intuition
tells me that there isn't enough interest in it from a project perspective.

From a user perspective, I've been getting asked about it when I work with
Accumulo users. My recommendation, exclusively, is to use HDFS encryption
because I can go to Hadoop's website and find documentation on it. When I
go to find documentation on Accumulo's offerings, any usability information
comes from vendor SlideShares. Most mentions of the feature on official
Apache Accumulo channels echo Christopher's sentiments on the feature being
experimental and not being officially recommended for use.

I wouldn't want to rip out the feature first and then figure things out
later. Sean already alluded to it, but a roadmap should contain something
(tool or documentation) to help users migrate if we go down that route.

What I'm trying to figure out is, when the question of "How do I do
encryption at rest in Accumulo?" comes up, what is our community's answer?

If we went down the route of using HDFS encryption zones, can we offer the
same features? At the very least, we'd be offering the same database-level
encryption scheme. I don't know the details of "more advanced key stores",
but it seems like we could potentially take any custom implementation and
map it to a KeyProvider [1]. I could also envision table level encryption
being implementable via zones, but probably not down to the column family

On Sun, Nov 1, 2015 at 10:19 AM, Adam Fuchs <[EMAIL PROTECTED]> wrote: