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
+
Keith Turner 2013-01-30, 19:26
+
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
Copy link to this message
-
Re: ACCUMULO-958 - Pluggable encryption in walogs
Aaron Cordova 2013-01-30, 18:29
Perhaps another option - it's not uncommon for a company, like Cloudera or RedHat, to add patches to their distribution for things they want to roll out earlier than the broader community wants them, among other reasons. Companies also often backport newer features to older releases.

Although one would certainly want to limit the extend of the patches.
On Jan 30, 2013, at 12:49 PM, [EMAIL PROTECTED] wrote:

>
>
>
>
>  - Josh has brought up some technical concerns with the patch
>
>
>
>  - Eric said that he would be fine adding it in 1.5.1 after testing
>
>
>
>  - Keith suggests that we don't change the public API for this if it is likely to change
>
>
>
> +1 to all of the above. I think it's ok to add portions of a feature as they mature, but it doesn't make sense to add something that we know is going to drastically change later. Feature branches are great for experiments. Regardless of whether somebody wants it, if we deliver it now, then they will use and be dependent on a new, non-complete, deprecated feature.
>
>
>
> Dave
>
>
>
> ----- Original Message -----
>
>
> From: "Keith Turner" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Wednesday, January 30, 2013 11:10:38 AM
> Subject: Re: ACCUMULO-958 - Pluggable encryption in walogs
>
> 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
>
> I do experiments all of the time w/o including half done things in a release.
>
> Should I include the following in 1.5.0 just so I can experiment with
> it?  I was working on it got sidetracked and never got back to it.  At
> this point I am uncertain of its utility. It needs further
> experimentation.
>
> https://github.com/keith-turner/accumulo/tree/ACCUMULO-551
>
>> 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.
>
> Back to ACCUMULO-551 I did experiements with that with not problem w/o
> including it in a release.  I just created a version of accumulo
> called accumulo-551-snapshot so no one would be confused if they
> encountered it.  What is wrong with the approach?
>
>> 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).
>
> Forking over this seems illogical.
>
> If we leave it in and hide it, then should all of the configuration
> properties be removed?
>
> I would consider the config props to be part of the public API and not
> easily modified in the future.  Since the props may change as the full
> implementation evolves, I think it would make sense to remove them
> from the public API.  If left, we should modify the config to support
> marking the config props as experimental and also modify the code that
> generates config documentation.  I just want to avoid boxing ourselves
> in or having to make things confusing for users.
>
>>
>> Adam
>>
>>
>>
>>
>> On Wed, Jan 30, 2013 at 10:09 AM, Eric Newton <[EMAIL PROTECTED]> wrote:
>>
>>> Some comments about the comments in ACCUMULO-958:
+
Mike Drob 2013-01-30, 22:42