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
Josh Elser 2013-01-31, 02:24
Given the discussion that's taken place today on this thread, I'd like
to bring back around the discussion and refocus my concerns, given
everyone else's comments, and perhaps generate some sort of summary,
boiling down to "what next".

First, my own opinions, despite how my actions may/may not have been
interpreted by others on this list, my reason for reviewing 958, and
furthermore starting this thread, is purely from a QA standpoint. I
would have not hesitated to start a similar discussion if the
contributor was a more-seasoned Accumulo dev than I (of which I consider
most to be), a coworker, former coworker, friend, stranger. I want to
strongly bring focus back to the point: I reviewed a patch from a new
contributor, I saw issues in the patch, gave (in my opinion) positive
feedback to the contributor and received no further comments after what
I consider a fair amount of time (5 days). My overarching reason for
escalating this issue is that I am concerned that the longer we wait to
*actually* finalize the first 1.5.0 release candidate, the less we will
actually test.

In less words, I saw *code* (not an individual) which I had issues with,
received no response to code review after a very quick patch
application, and wanted to test the waters to see if others also had
complaints.

(putting on my PMC hat to try to be unbiased, but *please* read for the
thread for yourself)

Trying to summarize what has been discussed, there is concern from
developers with the changes in regards to public API changes, lack of
unit/functional tests, the lack of an actual encryption policy (one that
encrypts) in the provided changes and the lack of a complete encryption
solution. On the other side, issues were raised about stifling
contributions due to a high barrier to entry to Accumulo which could
cause project division and the provided code is disabled by default
which shouldn't cause any harm to users/testers.

(putting my hat back on)

To voice my final opinion, I have *no* problem with including code for
encrypting WALs if someone will publicly sign up to bring the quality of
that code up to what I consider Accumulo-par. Meaning, someone signs up
to actively participate in review with the devs and adhere to future
deadlines of completion (so as to not delay a 1.5.0 release). I also
expect the creation of some basic functional tests to give "us" some
warm-fuzzies that the code doesn't create any performance issues. I
would *like* to see an implementation of encryption using these changes
(instead of just the promise), but I can understand if this is not
feasible given the time constraints of a 1.5.0 release (but please
explicitly tell the rest of us this if it is infeasible). I'm personally
not super-concerned about new config values being added across a major
release (public API).

Outside of the scope of just this issue, I'm going to 1) start thinking
about ways that we can quantify/automate the issue of QA contributions
to alleviate any future issues stemming from similar situations. 2) the
next time we have a feature-freeze, we need to be as explicit as
possible to avoid conflict (how can we make this process better).

- Josh

On 01/30/2013 03:13 PM, Benson Margulies wrote:
> 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.