Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB