Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> ACCUMULO-958 - Pluggable encryption in walogs

Copy link to this message
Re: ACCUMULO-958 - Pluggable encryption in walogs
It might be preferable if the patch included an example plugin.
Otherwise, it's a bit hard to see how an open process can evaluate the
design decisions, perhaps test a bit of performance, etc. I write this
without having read a line of code. If this is, in fact, very simple
and straightforward, then it might be a tempest in a teapot.

On Wed, Jan 30, 2013 at 2:26 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 30, 2013 at 2:02 PM, William Slacum
> <[EMAIL PROTECTED]> wrote:
>> Adam, I think you need to invert your premise. You need to consider the
>> benefit to the community of some piece of work before committing back to
>> the community. A plug-in framework has no value if there are no plug-ins.
>> Adding in untested, unreviewed layers of indirection for reading and
> We are CTR.  Any committer should be willing to open discussion and
> review of any change they make.  I feel that very reasonable questions
> about this change are not being answered or discussed.
>> writing data is a bad idea, plain and simple. Furthermore, you cannot say
>> you are avoiding forking by supplying the patch and then openly state you
>> are witholding portions that make said patch useful.
>> On Wed, Jan 30, 2013 at 1:45 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>>> Bill,
>>> The release date was not pushed back just for this ticket -- there were
>>> several other changes that motivated that date change. We can discuss that
>>> aspect separately from a discussion of ACCUMULO-958, and we need to start a
>>> separate thread to talk about the remaining milestones before the 1.5.0
>>> release.
>>> I would also like to amend your statement to be "... the patch has no value
>>> added [for] general users [without the addition of extensions that are not
>>> included with the patch]." This is a more accurate yet much weaker premise,
>>> and you should consider the implications on the broader ecosystem.
>>> It seems to me that the main points against this patch are that it is
>>> imperfect. I don't think that feature freeze is the time at which we should
>>> demand perfection. Several valid issues have been raised, which should be
>>> fixed by code freeze (the date of which is not yet set). However, the
>>> utility of this work is obvious to me. At the end of the day, what bar are
>>> we trying to set for inclusion of a patch?
>>> Adam
>>> On Wed, Jan 30, 2013 at 11:05 AM, William Slacum <
>>> [EMAIL PROTECTED]> wrote:
>>> > Bottom line, the patch has no value added to general users. The idea
>>> behind
>>> > pushing back a release date to stuff in unoperational code is very bad
>>> > practice. It sets a precedent for not considering alternative approaches
>>> > while simultaneously having no justification for choosing the approach we
>>> > did. If a specific customer/group/person wants a feature, and that
>>> feature
>>> > does not exist yet, the code is freely available to be modified,
>>> > distributed and open to public review. Adam, I strongly disagree that
>>> > forking the code is bad, considering the progress that other projects
>>> make
>>> > specifically because they have experimental forks (HBase).
>>> >
>>> > On Wed, Jan 30, 2013 at 10:40 AM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>>> >
>>> > > Let me attempt to make another argument for why the 958 patch should be
>>> > > included in 1.5.0. What this patch represents is not an encryption
>>> > solution
>>> > > for WAL, but an experimental extension point that will be used for
>>> > building
>>> > > an encryption solution as a pluggable module. We need to judge its
>>> merit
>>> > > based on whether it is a successful experimental extension point or
>>> not.
>>> > > There are three main reasons for including the patch in 1.5.0:
>>> > > 1. Test the performance impact of the null cipher solution (default
>>> > > configuration) in all the performance tests we will be running for the
>>> > > 1.5.0 release. If it causes problems there then we can roll it back.