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

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


+
Josh Elser 2013-01-30, 14:13
+
Adam Fuchs 2013-01-30, 14:50
+
Adam Fuchs 2013-01-30, 14:51
+
Eric Newton 2013-01-30, 15:09
+
Adam Fuchs 2013-01-30, 15:40
+
William Slacum 2013-01-30, 16:05
+
Adam Fuchs 2013-01-30, 18:45
+
Keith Turner 2013-01-30, 19:20
+
William Slacum 2013-01-30, 19:02
Copy link to this message
-
Re: ACCUMULO-958 - Pluggable encryption in walogs
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.
>> > > 2. Enable the use of this extension after 1.5 is released. External
>> > > experiments have dependencies on this extension point. Without the
>> > > extension point we will have to test with unreleased versions of
>> > Accumulo,
>> > > which would be less than ideal.
>> > > 3. It is not harmful and somebody wants it. The reason for wanting this
>> > > code in is well documented, so you need a very strong reason to throw
>> it
>> > > out. Otherwise you will encourage forking of the project (which would
+
Benson Margulies 2013-01-30, 20:13
+
Josh Elser 2013-01-31, 02:24
+
Keith Turner 2013-01-30, 16:10
+
dlmarion@... 2013-01-30, 17:49
+
Aaron Cordova 2013-01-30, 18:29
+
Mike Drob 2013-01-30, 22:42