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
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?

The patch is already included.  Its being reviewed.

My main concern is the public API, specifically the config props.  I
think its very likely there will be a desire to change them once this
feature is fully implemented.  Whats the strategy for dealing with

Personally, I am not strongly opposed to including the code.  We
already have useless code floating around in various places.  I am
strongly opposed to the API changes.

> Adam
> On Wed, Jan 30, 2013 at 11:05 AM, William Slacum <
>> 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 be
>> > bad).
>> >
>> > Adam
>> >
>> >
>> >
>> >
>> > On Wed, Jan 30, 2013 at 10:09 AM, Eric Newton <[EMAIL PROTECTED]>
>> > wrote:
>> >
>> > > Some comments about the comments in ACCUMULO-958:
>> > >
>> > > Josh writes:
>> > >
>> > > "We still have the ability to review this even after the feature freeze
>> > > happens, it's just frustrating from my point of view in generating the
>> > best