Re: New Committers/PMC members!

[Corey Nolet]

Welcome, guys!

On Thu, Sep 1, 2016 at 9:53 AM, Billie Rinaldi 
wrote:

> Welcome, Mike and Marc!
>
> On Wed, Aug 31, 2016 at 7:58 AM, Josh Elser  wrote:
>
> > Hiya folks,
> >
> > I wanted to take a moment to publicly announce some recent additions to
> > the Apache Accumulo family (committers and PMC).
> >
> > We had Mike Wall join the ranks back in April (sorry for the delayed
> > announcement!) and Marc Parisi has just joined us this week.
> >
> > Thank you both for your continued contributions to the project and we all
> > look forward to working with you more!
> >
> > - Josh (on behalf of Apache Accumulo)
> >
>

Re: Hadoop

[Corey Nolet]

This may not be directly related but I've noticed Hadoop packages have been
not uninstalling/updating well the past year or so. The last couple times
I've run fedup, I've had to go back in manually and remove/update a bunch
of the Hadoop packages like Zookeeper and Parquet.

On Thu, Jun 2, 2016 at 4:59 PM, Christopher 
wrote:

> That first post was intended for the Fedora developer list. Apologies for
> sending to the wrong list.
>
> If anybody is curious, it seems the Fedora community support around Hadoop
> and Big Data is really dying... the packager for Flume and HTrace has
> abandoned their efforts to package for Fedora, and now it looks like the
> Hadoop package maintainer abandoned Hadoop, leaving Accumulo with
> unsatisfied dependencies. This is actually kind of a sad state of affairs,
> because better packaging downstream could really help users, and expose
> more ways to improve the upstream products.
>
> As it stands, I think there is a disconnect between the upstream
> communities and the downstream packagers in the Big Data space which
> includes Accumulo. I would love to see more interest in better packaging
> for downstream users through these existing downstream packager communities
> (Homebrew, Fedora, Debian, EPEL, Ubuntu, etc.), and I would love to see
> more volunteers come from these downstream communities to make improvements
> upstream.
>
> As an upstream community, I believe the responsibility is for us to reach
> down first, rather than wait for them to come to us. I've tried to do that
> within Fedora, with the hope that others would follow for the downstream
> communities they care about. Unfortunately, things haven't turned out how
> I'd have preferred, but I'm still hopeful. If there is anybody interested
> in downstream community packaging, let me know if I can help you get
> started.
>
> On Thu, Jun 2, 2016 at 4:28 PM Christopher 
> wrote:
>
> > Sorry, wrong list.
> >
> > On Thu, Jun 2, 2016 at 4:20 PM Christopher 
> > wrote:
> >
> >> So, it would seem at some point, without me noticing (certainly my
> fault,
> >> for not paying attention enough), the Hadoop packages got orphaned
> and/or
> >> retired? in Fedora.
> >>
> >> This is a big problem for me, because the main package I work on is
> >> dependent upon Hadoop.
> >>
> >> What's the state of Hadoop in Fedora these days? Are there packaging
> >> problems? Not enough support from upstream Apache community? Missing
> >> dependencies in Fedora? Not enough time to work on it? No interest from
> >> users?
> >>
> >> Whatever the issue is... I'd like to help wherever I can... I'd like to
> >> keep this stuff going.
> >>
> >
>

Re: Post 1.5.3 and 1.6.3

[Corey Nolet]

+1 on the happy hour!

On Mon, Jul 6, 2015 at 5:58 PM, Eric Newton eric.new...@gmail.com wrote:

 More importantly, when are we going to have a happy hour to celebrate?

 -Eric


 On Mon, Jul 6, 2015 at 4:04 PM, Josh Elser josh.el...@gmail.com wrote:

  Thanks to the efforts spearheaded by Christopher and verified by everyone
  else, we now have 1.5.3 and 1.6.3 releases!
 
  To keep the ball rolling, what's next? High level questions that come to
  mind...
 
  * When do we do 1.7.1 and/or 1.8.0?
  * What bug-fixes do we have outstanding for 1.7.1?
  * What other minor improvements do people want for 1.8.0?
  * Where does 2.0.0 stand? Should we make a bigger effort to getting the
  new client API stuff Christopher had started into Apache?
 
  Feel free to brainstorm here and/or on JIRA (tagging relevant issues to
  the desired fixVersion)
 
  - Josh
 

Re: 1.5.3 and 1.6.3

[Corey Nolet]

I can get a 1.6.3 together.

On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote:

 Sure, we can discuss that separately. I'll start a new thread.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote:
  let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5.
 
  On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org
 wrote:
 
  And, whether or not we release 1.5.3, I do think we should consider
  closing out development on that branch after 1.7.0 is released.
  Anybody have any thoughts on that?
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org
 wrote:
   I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75
   and 82 commits in those branches, presumably fixing a lot of bugs.
  
   Is anybody willing to act as release manager for either of these and
   prepare the RCs? Perhaps somebody who hasn't already done some
   releases who wants to try?
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
 
 
 
 
  --
  Sean

Re: 1.5.3 and 1.6.3

[Corey Nolet]

That is, unless any of the new committers would like to take it on- in that
case, I can help ;-)

On Tue, May 12, 2015 at 3:41 PM, Corey Nolet cjno...@gmail.com wrote:

 I can get a 1.6.3 together.


 On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote:

 Sure, we can discuss that separately. I'll start a new thread.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote:
  let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5.
 
  On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org
 wrote:
 
  And, whether or not we release 1.5.3, I do think we should consider
  closing out development on that branch after 1.7.0 is released.
  Anybody have any thoughts on that?
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org
 wrote:
   I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75
   and 82 commits in those branches, presumably fixing a lot of bugs.
  
   Is anybody willing to act as release manager for either of these and
   prepare the RCs? Perhaps somebody who hasn't already done some
   releases who wants to try?
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
 
 
 
 
  --
  Sean

Re: [VOTE] Establishing a contrib repo for upgrade testing

[Corey Nolet]

+1

On Tue, Mar 10, 2015 at 10:57 AM, David Medinets david.medin...@gmail.com
wrote:

 +1

 On Tue, Mar 10, 2015 at 10:56 AM, Adam Fuchs afu...@apache.org wrote:
  +1
 
  Adam
  On Mar 10, 2015 2:48 AM, Sean Busbey bus...@cloudera.com wrote:
 
  Hi Accumulo!
 
  This is the VOTE thread following our DISCUSS thread on establishing a
 new
  contrib for upgrade testing. For more details, please see the prior
 DISCUSS
  thread on this topic[1].
 
  Cloudera has recently made public some code used for doing correctness
  testing for Accumulo installations across upgrades[2]. The project
 contains
  simple data load and verification tools as well as a rudimentary upgrade
  test automation script. Cloudera would like to donate this code to the
 ASF
  and use it as a starting place for a contrib repository focused on
 testing
  Accumulo across versions generally.
 
  Upon passage of this vote, the Accumulo PMC will adopt this repo as a
 code
  base for the new project contrib accumulo-upgrade-tests subject to the
  ASF IP clearance process[3].
 
  Either as a part of the IP clearance process or immediately thereafter
 the
  repo's docs, artifacts, and packages will be updated to make use of ASF
  releases ad naming conventions rather than vendor specific materials.
 
  I (Sean Busbey) have volunteered to shepherd the paperwork in the IP
  clearance process, handle the updates to ASF releases, and serve as
  component lead for a new Jira component to cover the contrib.
 
  Note that as a contrib repository, the artifacts from this repo will be
  versioned independently from the primary Accumulo codebase. While this
 repo
  seeks to be useful for testing across Accumulo releases, this proposal
 does
  not establish any requirement for its use on release candidates of the
  primary codebase.
 
  Per our bylaws, this vote will require consensus approval (at least 3
  binding +1 votes and no binding vetoes). Though only PMC votes are
 binding,
  all community members are encouraged to vote.
 
  The vote will remain open until 0700 GMT Tuesday March 17 2015 (0300
 EDT).
 
  Please vote one of:
 
  [ ] +1: Establish the 'accumulo-upgrade-tests' contrib by adopting the
  codebase as described
  [ ] -1: Do not adopt the codebase because ...
 
 
  [1]: http://s.apache.org/MsR
  [2]: https://github.com/cloudera/accumulo-upgrade-test/
  [3]: http://incubator.apache.org/ip-clearance/
 
  --
  Sean
 

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

Thanks Keith!. Josh deserves credit for the release notes.

We'll publish the site and I'll get the announcement together.

On Wed, Feb 18, 2015 at 11:34 AM, Josh Elser josh.el...@gmail.com wrote:

 +1 ditto. Mirrors appear updated as well. I just fixed another
 s/1.6.1/1.6.2/ on the sidebar. I think we're all good.


 Keith Turner wrote:

 Corey thanks for doing this release.  I took a look at the release notes
 on
 staging, looks good.



 On Wed, Feb 11, 2015 at 8:52 AM, Corey Noletcjno...@apache.org  wrote:

 Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/

  Source tarball:

 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz
  Binary tarball:

 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash
 for a
 given artifact.)

  Signing keys available at: https://www.apache.org/dist/
 accumulo/KEYS

  Over 1.6.1, we have 159 issues resolved:

 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc5

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:

 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:

 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, February 14th 12:00AM UTC
 (2/13
 8:00PM ET, 2/13 5:00PM PT)

Fwd: [ANNOUNCE] Apache Accumulo 1.6.2 Released

[Corey Nolet]

Forwarding to dev.


-- Forwarded message --
From: Corey Nolet cjno...@apache.org
Date: Wed, Feb 18, 2015 at 12:25 PM
Subject: [ANNOUNCE] Apache Accumulo 1.6.2 Released
To: u...@accumulo.apache.org, annou...@apache.org


The Apache Accumulo project is happy to announce its 1.6.2 release.

Version 1.6.2 is the most recent bug-fix release in its 1.6.x release line.
This version includes numerous bug fixes as well as a performance
improvement over previous versions. Existing users of 1.6.x are encouraged
to upgrade to this version. Users new to Accumulo are encouraged to start
with this version as well.

The Apache Accumulo sorted, distributed key/value store is a robust,
scalable, high performance data storage system that features cell-based
access control and customizable server-side processing.  It is based on
Google's BigTable design and is built on top of Apache Hadoop, Apache
Zookeeper, and Apache Thrift.

The release is available at http://accumulo.apache.org/downloads/ and
release notes at http://accumulo.apache.org/release_notes/1.6.2.html.


Thanks.

- The Apache Accumulo Team

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

Josh- I'm terribly busy this weekend but I am going to tackle the release
notes, publishing the artifacts to the website, and javadocs tomorrow since
I'm off work. We'll need to get the manual out on the website. I can do
that tomorrow as well.

On Sat, Feb 14, 2015 at 7:06 PM, Josh Elser josh.el...@gmail.com wrote:

 Great work, Corey!

 What else do we need to do? Release notes? Do you have the
 javadoc/artifact deployments under control?


 Corey Nolet wrote:

 The vote is now closed. The release of Apache Accumulo 1.6.2 RC5 has been
 accepted with 3 +1's and 0 -1's.


 On Fri, Feb 13, 2015 at 5:59 PM, Keith Turnerke...@deenlo.com  wrote:

  +1

 I was able to build Fluo against RC5 w/ no problem.  Also I determined
 ACCUMULO-3597 is not new in 1.6.2.Because of ACCUMULO-3597, I was not
 able to get a long randomwalk run.   The bug happened shortly after
 starting the test.   I killed the deadlocked tserver and everything
 started
 running again.



 On Wed, Feb 11, 2015 at 8:52 AM, Corey Noletcjno...@apache.org  wrote:

 Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:

  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/

  Source tarball:


  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz

  Binary tarball:


  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz

  (Append .sha1, .md5 or .asc to download the signature/hash
 for

 a

 given artifact.)

  Signing keys available at: https://www.apache.org/dist/
 accumulo/KEYS

  Over 1.6.1, we have 159 issues resolved:


  https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc5

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:


  http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:


  http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, February 14th 12:00AM UTC
 (2/13
 8:00PM ET, 2/13 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

Billie took on the user manual last time. I'm still not sure how to build
the website output for that.

On Sun, Feb 15, 2015 at 8:58 AM, Corey Nolet cjno...@gmail.com wrote:

 Josh- I'm terribly busy this weekend but I am going to tackle the release
 notes, publishing the artifacts to the website, and javadocs tomorrow since
 I'm off work. We'll need to get the manual out on the website. I can do
 that tomorrow as well.

 On Sat, Feb 14, 2015 at 7:06 PM, Josh Elser josh.el...@gmail.com wrote:

 Great work, Corey!

 What else do we need to do? Release notes? Do you have the
 javadoc/artifact deployments under control?


 Corey Nolet wrote:

 The vote is now closed. The release of Apache Accumulo 1.6.2 RC5 has been
 accepted with 3 +1's and 0 -1's.


 On Fri, Feb 13, 2015 at 5:59 PM, Keith Turnerke...@deenlo.com  wrote:

  +1

 I was able to build Fluo against RC5 w/ no problem.  Also I determined
 ACCUMULO-3597 is not new in 1.6.2.Because of ACCUMULO-3597, I was
 not
 able to get a long randomwalk run.   The bug happened shortly after
 starting the test.   I killed the deadlocked tserver and everything
 started
 running again.



 On Wed, Feb 11, 2015 at 8:52 AM, Corey Noletcjno...@apache.org
 wrote:

 Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:

  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/

  Source tarball:


  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz

  Binary tarball:


  https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz

  (Append .sha1, .md5 or .asc to download the signature/hash
 for

 a

 given artifact.)

  Signing keys available at: https://www.apache.org/dist/
 accumulo/KEYS

  Over 1.6.1, we have 159 issues resolved:


  https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc5

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:


  http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:


  http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, February 14th 12:00AM UTC
 (2/13
 8:00PM ET, 2/13 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

The vote is now closed. The release of Apache Accumulo 1.6.2 RC5 has been
accepted with 3 +1's and 0 -1's.


On Fri, Feb 13, 2015 at 5:59 PM, Keith Turner ke...@deenlo.com wrote:

 +1

 I was able to build Fluo against RC5 w/ no problem.  Also I determined
 ACCUMULO-3597 is not new in 1.6.2.Because of ACCUMULO-3597, I was not
 able to get a long randomwalk run.   The bug happened shortly after
 starting the test.   I killed the deadlocked tserver and everything started
 running again.



 On Wed, Feb 11, 2015 at 8:52 AM, Corey Nolet cjno...@apache.org wrote:

Devs,
 
  Please consider the following candidate for Apache Accumulo 1.6.2
 
  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/
 
  Source tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
  given artifact.)
 
  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
 
  Over 1.6.1, we have 159 issues resolved:
 
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc5
 
  Testing: All unit, integration and functional tests are passing.
 
  API compatibility report for 1.6.1 to 1.6.2:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html
 
  API backwards compatibility report for 1.6.2 to 1.6.1:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html
 
  The vote will be open until Saturday, February 14th 12:00AM UTC (2/13
  8:00PM ET, 2/13 5:00PM PT)
 

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

Thanks Josh for your verification. Just a reminder that this vote closes in
6.5 hours.

On Thu, Feb 12, 2015 at 5:59 PM, Josh Elser els...@apache.org wrote:

 +1

 * Verified all changes over RC4 are present
 * Hashes/sigs good
 * ran from bin tarball
 * built/tested from src tarball
 * Verified NOTICE in native.tar.gz


 Corey Nolet wrote:

Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/

  Source tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
 given artifact.)

  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

  Over 1.6.1, we have 159 issues resolved:
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc5

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, February 14th 12:00AM UTC (2/13
 8:00PM ET, 2/13 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

With this being the fifth release candidate, I originally wanted to get the
vote closed before the weekend. Our bylaws do state that there's a 72-hour
minimum and a fifth release candidate shouldn't be an exception to that.
I'm going to extend the original vote closing time to be 72 hours after
time at which the RC5 was announced, which was 2pm UTC on Wednesday,
February 11th.

That would make the vote close on  Saturday, February 14th at 2pm UTC (9am
EST, 6am PT)

On Fri, Feb 13, 2015 at 1:38 PM, Corey Nolet cjno...@gmail.com wrote:

 Thanks Josh for your verification. Just a reminder that this vote closes
 in 6.5 hours.

 On Thu, Feb 12, 2015 at 5:59 PM, Josh Elser els...@apache.org wrote:

 +1

 * Verified all changes over RC4 are present
 * Hashes/sigs good
 * ran from bin tarball
 * built/tested from src tarball
 * Verified NOTICE in native.tar.gz


 Corey Nolet wrote:

Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc5
  SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
  Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/

  Source tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash
 for a
 given artifact.)

  Signing keys available at: https://www.apache.org/dist/
 accumulo/KEYS

  Over 1.6.1, we have 159 issues resolved:
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc5

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/
 compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, February 14th 12:00AM UTC
 (2/13
 8:00PM ET, 2/13 5:00PM PT)

[VOTE] Apache Accumulo 1.6.2 RC5

[Corey Nolet]

  Devs,

Please consider the following candidate for Apache Accumulo 1.6.2

Branch: 1.6.2-rc5
SHA1: 42943a1817434f1f32e9f0224941aa2fff162e74
Staging Repository:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/

Source tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
Binary tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1024/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
(Append .sha1, .md5 or .asc to download the signature/hash for a
given artifact.)

Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

Over 1.6.1, we have 159 issues resolved:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc5

Testing: All unit, integration and functional tests are passing.

API compatibility report for 1.6.1 to 1.6.2:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/compat_reports/Accumulo/1.6.1_to_1.6.2/compat_report.html

API backwards compatibility report for 1.6.2 to 1.6.1:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc5/compat_reports/Accumulo/1.6.2_to_1.6.1/compat_report.html

The vote will be open until Saturday, February 14th 12:00AM UTC (2/13
8:00PM ET, 2/13 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.2 RC4

[Corey Nolet]

This vote has come to a close with the following result:

+1: 2
-1: 1

I'll get an RC5 together.

On Tue, Feb 10, 2015 at 7:06 PM, Keith Turner ke...@deenlo.com wrote:

 -1 because is causing mini accumulo to not run ACCUMULO-3576

 On the upside I made two successful 24 hr ci runs.   One with agitation and
 one without.

 For the one w/o agitation I ran into some hdfs issue and opened HDFS-7765.
 I think I ingested around ~31 billion entries.

 For the test run w/ agitation I ran into the following issues :

   * ACCUMULO-3575
   * ACCUMULO-2247

 w/ agitation, ran for 26 hrs and wrote 21 billion entries.

 https://issues.apache.org/jira/browse/ACCUMULO-3576

 On Thu, Feb 5, 2015 at 11:00 PM, Corey Nolet cjno...@apache.org wrote:

Devs,
 
  Please consider the following candidate for Apache Accumulo 1.6.2
 
  Branch: 1.6.2-rc4
  SHA1: 0649982c2e395852ce2e4408d283a40d6490a980
  Staging Repository:
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/
 
  Source tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
  given artifact.)
 
  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
 
  Over 1.6.1, we have 153 issues resolved:
 
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc4
 
  Testing: All unit, integration and functional tests are passing.
 
  API compatibility report for 1.6.1 to 1.6.2:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html
 
  API backwards compatibility report for 1.6.2 to 1.6.1:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html
 
  The vote will be open until Tuesday, February 10th 12:00AM UTC (2/09
  8:00PM ET, 2/09 5:00PM PT)
 

Re: [VOTE] Apache Accumulo 1.6.2 RC4

[Corey Nolet]

I'll add this to the release documentation as well.


On Fri, Feb 6, 2015 at 12:04 PM, Christopher ctubb...@apache.org wrote:

 Just a quick observation:

 The CHANGES file omits ACCUMULO-2696 and ACCUMULO-3517, which were marked
 (tentatively) as fixed for 1.6.3, but actually were included in RC4.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Feb 5, 2015 at 11:00 PM, Corey Nolet cjno...@apache.org wrote:

Devs,
 
  Please consider the following candidate for Apache Accumulo 1.6.2
 
  Branch: 1.6.2-rc4
  SHA1: 0649982c2e395852ce2e4408d283a40d6490a980
  Staging Repository:
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/
 
  Source tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
  given artifact.)
 
  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
 
  Over 1.6.1, we have 153 issues resolved:
 
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc4
 
  Testing: All unit, integration and functional tests are passing.
 
  API compatibility report for 1.6.1 to 1.6.2:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html
 
  API backwards compatibility report for 1.6.2 to 1.6.1:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html
 
  The vote will be open until Tuesday, February 10th 12:00AM UTC (2/09
  8:00PM ET, 2/09 5:00PM PT)
 

[VOTE] Apache Accumulo 1.6.2 RC4

[Corey Nolet]

  Devs,

Please consider the following candidate for Apache Accumulo 1.6.2

Branch: 1.6.2-rc4
SHA1: 0649982c2e395852ce2e4408d283a40d6490a980
Staging Repository:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/

Source tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
Binary tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1022/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
(Append .sha1, .md5 or .asc to download the signature/hash for a
given artifact.)

Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

Over 1.6.1, we have 153 issues resolved:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc4

Testing: All unit, integration and functional tests are passing.

API compatibility report for 1.6.1 to 1.6.2:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html

API backwards compatibility report for 1.6.2 to 1.6.1:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc4/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html

The vote will be open until Tuesday, February 10th 12:00AM UTC (2/09
8:00PM ET, 2/09 5:00PM PT)

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/
---

(Updated Feb. 4, 2015, 3:10 p.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Changes
---

Add JIRA link


Bugs: ACCUMULO-2793
https://issues.apache.org/jira/browse/ACCUMULO-2793


Repository: accumulo


Description
---

ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
well as an error message when a replaced instance appears in instance.volumes


Diffs
-

  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 4b917d1 
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
51fa47e 
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
e0a3797 

Diff: https://reviews.apache.org/r/29959/diff/


Testing
---

Built the manual and found that the page numbers aren't aligning with the table 
of contents. Opened up ACCUMULO-3486 to address this. Still need to verify if 
it's a recent bug or if it's been around for awhile.

Physically tested the error message appears when 'bin/accumulo init 
--add-volumes' is called and a replaced volume appears in instance.volumes. 
Also verified that the error does not appear when 'bin/accumulo init 
--add-volumes' is called and the replaced volume does not appear in 
instance.volumes


Thanks,

Corey Nolet

Re: [VOTE] Apache Accumulo 1.6.2 RC3

[Corey Nolet]

I have RC4 staged and ready. I'll hold off until tonight (Thursday) to fire
off the vote to give the community time to verify recent changes in the
1.6.1 branch.

On Fri, Jan 30, 2015 at 7:20 PM, Eric Newton eric.new...@gmail.com wrote:

 -0

 It would be nice to have ACCUMULO-3547
 https://issues.apache.org/jira/browse/ACCUMULO-3549 in 1.6.2.

 We are running at scale with it at the moment, and it has made a huge
 improvement.  I hate to hold up 1.6.2, though.  If it doesn't make it,
 please update the ticket to point to 1.6.3.

 Corey, thanks for all your effort.

 -Eric

 On Fri, Jan 30, 2015 at 10:36 AM, Keith Turner ke...@deenlo.com wrote:

  On Thu, Jan 29, 2015 at 7:27 PM, Corey Nolet cjno...@gmail.com wrote:
 
However I am seeing ACCUMULO-3545[1] that
   I need to investigate.
  
   Ok. I'll cut another RC as soon as that's complete.
  
 
  Verification completed.   Successfully wrote and verified 31B entries on
 a
  20 nodes EC2 cluster.   Used Hadoop 2.6.0, ZK 3.4.5, Centos 6, and
 openjdk
  7.
 
 
  
   On Thu, Jan 29, 2015 at 6:03 PM, Josh Elser josh.el...@gmail.com
  wrote:
  
Given the stuff Keith found already, I'm -1, but I did take some time
   this
RC to rerun some tests. I had one IT that failed on me from the
 source
build which we can fix later -- things are looking good otherwise
 from
  my
testing.
   
Thanks for working through this Corey, and Keith for finding bugs :)
   
   
Corey Nolet wrote:
   
   Devs,
   
 Please consider the following candidate for Apache Accumulo
 1.6.2
   
 Branch: 1.6.2-rc3
 SHA1: 3a6987470c1e5090a2ca159614a80f0fa50393bf
 Staging Repository:
https://repository.apache.org/content/repositories/
orgapacheaccumulo-1021/
   
 Source tarball:
https://repository.apache.org/content/repositories/
orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.
2/accumulo-1.6.2-src.tar.gz
 Binary tarball:
https://repository.apache.org/content/repositories/
orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.
2/accumulo-1.6.2-bin.tar.gz
 (Append .sha1, .md5 or .asc to download the
 signature/hash
   for
a
given artifact.)
   
 Signing keys available at:
   https://www.apache.org/dist/accumulo/KEYS
   
 Over 1.6.1, we have 148 issues resolved:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
blob_plain;f=CHANGES;hb=1.6.2-rc3
   
 Testing: All unit, integration and functional tests are
 passing.
   
 API compatibility report for 1.6.1 to 1.6.2:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/
compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html
   
 API backwards compatibility report for 1.6.2 to 1.6.1:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/
compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html
   
 The vote will be open until Saturday, January 31st 12:00AM UTC
   (1/30
8:00PM ET, 1/30 5:00PM PT)
   
   
  
 

Re: [VOTE] Apache Accumulo 1.6.2 RC3

[Corey Nolet]

 However I am seeing ACCUMULO-3545[1] that
I need to investigate.

Ok. I'll cut another RC as soon as that's complete.

On Thu, Jan 29, 2015 at 6:03 PM, Josh Elser josh.el...@gmail.com wrote:

 Given the stuff Keith found already, I'm -1, but I did take some time this
 RC to rerun some tests. I had one IT that failed on me from the source
 build which we can fix later -- things are looking good otherwise from my
 testing.

 Thanks for working through this Corey, and Keith for finding bugs :)


 Corey Nolet wrote:

Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc3
  SHA1: 3a6987470c1e5090a2ca159614a80f0fa50393bf
  Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1021/

  Source tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
 given artifact.)

  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

  Over 1.6.1, we have 148 issues resolved:
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob_plain;f=CHANGES;hb=1.6.2-rc3

  Testing: All unit, integration and functional tests are passing.

  API compatibility report for 1.6.1 to 1.6.2:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/
 compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html

  API backwards compatibility report for 1.6.2 to 1.6.1:
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/
 compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html

  The vote will be open until Saturday, January 31st 12:00AM UTC (1/30
 8:00PM ET, 1/30 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.2 RC3

[Corey Nolet]

Ok. I'm documenting this in the release procedures I've been working on and
will cut RC4 with jdk1.6. I think its fair at this point to steer
developers towards just cutting the release with the actual jdk version
that matches the version of the bytecode.
On Jan 28, 2015 7:18 PM, Christopher ctubb...@apache.org wrote:

 On Wed, Jan 28, 2015 at 2:30 PM, Sean Busbey bus...@cloudera.com wrote:
 [snip]

  So that looks fine. I have seen cases before where using the maven
 compiler
  plugin's -source -target options without the correct rt.jar file resulted
  in Java 6 JVM compatible class files that still referenced JRE classes
 that
  weren't available.
 
 
 Right, my main concern was this kind of problem (which I think can be
 resolved by setting bootstrap classpath during compile).


  Attempting to compile the source tarball with a Java 6 JDK should cause
  that to show up.

 [snip]

 That's what I'd hope also, but I think there are fringe cases that wouldn't
 catch this: use of constants which differ in value between versions,
 changes between interface/abstract class, and maybe a few other fringe
 cases that wouldn't be caught at compile time, but could cause runtime
 errors. (I'm no expert on this, though, which is why I phrased it as a
 question initially.)


  (as an aside, I couldn't find us actually documenting anywhere in the
 user
  manual or README what java versions we support.)
 
 
 Maybe it'd be good to document it somewhere, but the java version is
 specified in the pom, and has been:
 Java 6 or newer for Accumulo  1.7
 Java 7 or newer for Accumulo = 1.7

 FWIW, we don't really document any other compatible dependency versions
 either, outside the pom.xml, but divergence from this I'd typically expect
 a downstream package maintainer to deal with (except for the fact that many
 people use the upstream binaries directly, and that's a valid support case
 for our community). More FWIW: if we were using maven to generate a site,
 this kind of documentation could be generated automatically.


  On Wed, Jan 28, 2015 at 11:25 AM, Christopher ctubb...@apache.org
  https://mail.google.com/mail/?view=cmfs=1tf=1to=ctubb...@apache.org
 
  wrote:
 
   Does it matter that this was built with Java 1.7.0_25? Is that going to
   cause issues running in a 1.6 JRE?
  
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
   On Wed, Jan 28, 2015 at 2:38 AM, Corey Nolet cjno...@apache.org
   https://mail.google.com/mail/?view=cmfs=1tf=1to=cjno...@apache.org
 
   wrote:
  
  Devs,
   
Please consider the following candidate for Apache Accumulo 1.6.2
   
Branch: 1.6.2-rc3
SHA1: 3a6987470c1e5090a2ca159614a80f0fa50393bf
Staging Repository:
   
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/
   
Source tarball:
   
   
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
Binary tarball:
   
   
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
(Append .sha1, .md5 or .asc to download the signature/hash
  for
   a
given artifact.)
   
Signing keys available at:
  https://www.apache.org/dist/accumulo/KEYS
   
Over 1.6.1, we have 148 issues resolved:
   
   
  
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc3
   
Testing: All unit, integration and functional tests are passing.
   
API compatibility report for 1.6.1 to 1.6.2:
   
   
  
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html
   
API backwards compatibility report for 1.6.2 to 1.6.1:
   
   
  
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html
   
The vote will be open until Saturday, January 31st 12:00AM UTC
  (1/30
8:00PM ET, 1/30 5:00PM PT)
   
  
 
 
 
  --
  Sean
 

Re: [VOTE] Apache Accumulo 1.6.2 RC3

[Corey Nolet]

I'll start on an RC4 but leave this open for awhile in case any more issues
like pop up like this.
On Jan 28, 2015 5:24 PM, Keith Turner ke...@deenlo.com wrote:

 -1 because of ACCUMULO-3541

 On Wed, Jan 28, 2015 at 2:38 AM, Corey Nolet cjno...@apache.org wrote:

Devs,
 
  Please consider the following candidate for Apache Accumulo 1.6.2
 
  Branch: 1.6.2-rc3
  SHA1: 3a6987470c1e5090a2ca159614a80f0fa50393bf
  Staging Repository:
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/
 
  Source tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the signature/hash for
 a
  given artifact.)
 
  Signing keys available at: https://www.apache.org/dist/accumulo/KEYS
 
  Over 1.6.1, we have 148 issues resolved:
 
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc3
 
  Testing: All unit, integration and functional tests are passing.
 
  API compatibility report for 1.6.1 to 1.6.2:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html
 
  API backwards compatibility report for 1.6.2 to 1.6.1:
 
 
 http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html
 
  The vote will be open until Saturday, January 31st 12:00AM UTC (1/30
  8:00PM ET, 1/30 5:00PM PT)
 

[VOTE] Apache Accumulo 1.6.2 RC3

[Corey Nolet]

  Devs,

Please consider the following candidate for Apache Accumulo 1.6.2

Branch: 1.6.2-rc3
SHA1: 3a6987470c1e5090a2ca159614a80f0fa50393bf
Staging Repository:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/

Source tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
Binary tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1021/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
(Append .sha1, .md5 or .asc to download the signature/hash for a
given artifact.)

Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

Over 1.6.1, we have 148 issues resolved:
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=CHANGES;hb=1.6.2-rc3

Testing: All unit, integration and functional tests are passing.

API compatibility report for 1.6.1 to 1.6.2:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.1_to_1.6.2/compat_report.html

API backwards compatibility report for 1.6.2 to 1.6.1:
http://people.apache.org/~cjnolet/accumulo-1.6.2-rc3/compat_reports/accumulo/1.6.2_to_1.6.1/compat_report.html

The vote will be open until Saturday, January 31st 12:00AM UTC (1/30
8:00PM ET, 1/30 5:00PM PT)

Re: Review Request 30280: ACCUMULO-3533 Making AbstractInputFormat.getConfiguration() protected to match backwards compatibility with 1.6.1

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30280/
---

(Updated Jan. 26, 2015, 6:55 p.m.)


Review request for accumulo, Sean Busbey, Christopher Tubbs, Eric Newton, Josh 
Elser, and kturner.


Repository: accumulo


Description
---

ACCUMULO-3533 Moving the getConfiguration logic which uses reflection to 
guarantee Hadoop 1  2 compatiblity to its own util class outside of the public 
API. Making the AbstractInputFormat.getConfiguration() protected once again.


Diffs (updated)
-

  ACCUMULO-3533.patch PRE-CREATION 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AbstractInputFormat.java
 bcbfddc 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloFileOutputFormat.java
 c68dd56 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloMultiTableInputFormat.java
 010a94f 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloOutputFormat.java
 0f495f0 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java
 a60cb80 
  core/src/main/java/org/apache/accumulo/core/util/HadoopCompatUtil.java 
PRE-CREATION 
  
examples/simple/src/main/java/org/apache/accumulo/examples/simple/mapreduce/TeraSortIngest.java
 1b8cbaf 

Diff: https://reviews.apache.org/r/30280/diff/


Testing
---

Basic build with unit tests.


Thanks,

Corey Nolet

Re: Review Request 30280: ACCUMULO-3533 Making AbstractInputFormat.getConfiguration() protected to match backwards compatibility with 1.6.1

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30280/
---

(Updated Jan. 26, 2015, 7:04 p.m.)


Review request for accumulo, Sean Busbey, Christopher Tubbs, Eric Newton, Josh 
Elser, and kturner.


Bugs: ACCUMULO-3533
https://issues.apache.org/jira/browse/ACCUMULO-3533


Repository: accumulo


Description
---

ACCUMULO-3533 Moving the getConfiguration logic which uses reflection to 
guarantee Hadoop 1  2 compatiblity to its own util class outside of the public 
API. Making the AbstractInputFormat.getConfiguration() protected once again.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AbstractInputFormat.java
 bcbfddc 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloFileOutputFormat.java
 c68dd56 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloMultiTableInputFormat.java
 010a94f 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloOutputFormat.java
 0f495f0 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java
 a60cb80 
  core/src/main/java/org/apache/accumulo/core/util/HadoopCompatUtil.java 
PRE-CREATION 
  
examples/simple/src/main/java/org/apache/accumulo/examples/simple/mapreduce/TeraSortIngest.java
 1b8cbaf 

Diff: https://reviews.apache.org/r/30280/diff/


Testing
---

Basic build with unit tests.


Thanks,

Corey Nolet

Review Request 30280: ACCUMULO-3533 Making AbstractInputFormat.getConfiguration() protected to match backwards compatibility with 1.6.1

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30280/
---

Review request for accumulo, Sean Busbey, Christopher Tubbs, Eric Newton, Josh 
Elser, and kturner.


Repository: accumulo


Description
---

ACCUMULO-3533 Moving the getConfiguration logic which uses reflection to 
guarantee Hadoop 1  2 compatiblity to its own util class outside of the public 
API. Making the AbstractInputFormat.getConfiguration() protected once again.


Diffs
-

  ACCUMULO-3533.patch PRE-CREATION 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AbstractInputFormat.java
 bcbfddc 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloFileOutputFormat.java
 c68dd56 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloMultiTableInputFormat.java
 010a94f 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloOutputFormat.java
 0f495f0 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java
 a60cb80 
  core/src/main/java/org/apache/accumulo/core/util/HadoopCompatUtil.java 
PRE-CREATION 
  
examples/simple/src/main/java/org/apache/accumulo/examples/simple/mapreduce/TeraSortIngest.java
 1b8cbaf 

Diff: https://reviews.apache.org/r/30280/diff/


Testing
---

Basic build with unit tests.


Thanks,

Corey Nolet

Re: Review Request 30280: ACCUMULO-3533 Making AbstractInputFormat.getConfiguration() protected to match backwards compatibility with 1.6.1

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30280/
---

(Updated Jan. 26, 2015, 6:55 p.m.)


Review request for accumulo, Sean Busbey, Christopher Tubbs, Eric Newton, Josh 
Elser, and kturner.


Repository: accumulo


Description
---

ACCUMULO-3533 Moving the getConfiguration logic which uses reflection to 
guarantee Hadoop 1  2 compatiblity to its own util class outside of the public 
API. Making the AbstractInputFormat.getConfiguration() protected once again.


Diffs (updated)
-

  ACCUMULO-3533.patch PRE-CREATION 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AbstractInputFormat.java
 bcbfddc 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloFileOutputFormat.java
 c68dd56 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloMultiTableInputFormat.java
 010a94f 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloOutputFormat.java
 0f495f0 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java
 a60cb80 
  core/src/main/java/org/apache/accumulo/core/util/HadoopCompatUtil.java 
PRE-CREATION 
  
examples/simple/src/main/java/org/apache/accumulo/examples/simple/mapreduce/TeraSortIngest.java
 1b8cbaf 

Diff: https://reviews.apache.org/r/30280/diff/


Testing
---

Basic build with unit tests.


Thanks,

Corey Nolet

Re: Review Request 30280: ACCUMULO-3533 Making AbstractInputFormat.getConfiguration() protected to match backwards compatibility with 1.6.1

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30280/
---

(Updated Jan. 26, 2015, 2:02 p.m.)


Review request for accumulo, Sean Busbey, Christopher Tubbs, Eric Newton, Josh 
Elser, and kturner.


Bugs: ACCUMULO-3533
https://issues.apache.org/jira/browse/ACCUMULO-3533


Repository: accumulo


Description
---

ACCUMULO-3533 Moving the getConfiguration logic which uses reflection to 
guarantee Hadoop 1  2 compatiblity to its own util class outside of the public 
API. Making the AbstractInputFormat.getConfiguration() protected once again.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AbstractInputFormat.java
 bcbfddc 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloFileOutputFormat.java
 c68dd56 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloMultiTableInputFormat.java
 010a94f 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/AccumuloOutputFormat.java
 0f495f0 
  
core/src/main/java/org/apache/accumulo/core/client/mapreduce/InputFormatBase.java
 a60cb80 
  core/src/main/java/org/apache/accumulo/core/util/HadoopCompatUtil.java 
PRE-CREATION 
  
examples/simple/src/main/java/org/apache/accumulo/examples/simple/mapreduce/TeraSortIngest.java
 1b8cbaf 

Diff: https://reviews.apache.org/r/30280/diff/


Testing
---

Basic build with unit tests.


Thanks,

Corey Nolet

Re: Review Request 30252: ACCUMULO-3531 update japi-compliance-check configs.

[Corey Nolet]

I believe Josh just committed a fix for the missing license header.

On Mon, Jan 26, 2015 at 1:24 PM, Mike Drob md...@mdrob.com wrote:


 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/30252/#review69636
 ---



 test/compat/japi-compliance/exclude_classes.txt
 https://reviews.apache.org/r/30252/#comment114375

 This file is missing a license header and triggers the rat plugin.


 - Mike Drob


 On Jan. 25, 2015, 9:38 a.m., Sean Busbey wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  https://reviews.apache.org/r/30252/
  ---
 
  (Updated Jan. 25, 2015, 9:38 a.m.)
 
 
  Review request for accumulo.
 
 
  Bugs: ACCUMULO-3531
  https://issues.apache.org/jira/browse/ACCUMULO-3531
 
 
  Repository: accumulo
 
 
  Description
  ---
 
  ACCUMULO-3531 update japi-compliance-check configs.
 
 
  Diffs
  -
 
test/compat/japi-compliance/README
 8715f98109389346cb819f06db95345121f39cab
test/compat/japi-compliance/exclude_classes.txt PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.5.1.xml PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.5.2.xml PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.5.xml
test/compat/japi-compliance/japi-accumulo-1.6.0.xml PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.6.1.xml PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.6.2.xml PRE-CREATION
test/compat/japi-compliance/japi-accumulo-1.6.xml
 0403a963dcad5902ca19b07b6102a74131af
 
  Diff: https://reviews.apache.org/r/30252/diff/
 
 
  Testing
  ---
 
  generated these reports using given xml configs and following the
 included instructions in the README.
 
 
  Thanks,
 
  Sean Busbey
 
 

Re: Review Request 30252: ACCUMULO-3531 update japi-compliance-check configs.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30252/#review69569
---



test/compat/japi-compliance/README
https://reviews.apache.org/r/30252/#comment114283

Good. I'll add this to the release documentation I've been working on.


- Corey Nolet


On Jan. 25, 2015, 9:38 a.m., Sean Busbey wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/30252/
 ---
 
 (Updated Jan. 25, 2015, 9:38 a.m.)
 
 
 Review request for accumulo.
 
 
 Bugs: ACCUMULO-3531
 https://issues.apache.org/jira/browse/ACCUMULO-3531
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-3531 update japi-compliance-check configs.
 
 
 Diffs
 -
 
   test/compat/japi-compliance/README 8715f98109389346cb819f06db95345121f39cab 
   test/compat/japi-compliance/exclude_classes.txt PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.5.1.xml PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.5.2.xml PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.5.xml  
   test/compat/japi-compliance/japi-accumulo-1.6.0.xml PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.6.1.xml PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.6.2.xml PRE-CREATION 
   test/compat/japi-compliance/japi-accumulo-1.6.xml 
 0403a963dcad5902ca19b07b6102a74131af 
 
 Diff: https://reviews.apache.org/r/30252/diff/
 
 
 Testing
 ---
 
 generated these reports using given xml configs and following the included 
 instructions in the README.
 
 
 Thanks,
 
 Sean Busbey
 

Re: [VOTE] Apache Accumulo 1.6.2 RC2

[Corey Nolet]

Forwarding discussions to dev.
On Jan 25, 2015 3:22 PM, Josh Elser josh.el...@gmail.com wrote:

 plus, I don't think it's valid to call this vote on the user list :)

 Corey Nolet wrote:

 -1 for backwards compatibility issues described.

 -1

 Corey, I'm really sorry for the churn. I thought I ran both forward and
 backward compatibility modes last time (-old 1.6.1 -new 1.6.2 as well as
 -old 1.6.2 -new 1.6.1), but I must have just eyeballed the output of the
 1.6.1 - 1.6.2 report for problems with forward compatibility.

 I ran things again this time (as a formality) and the 1.6.2 - 1.6.1
 check turned up 2 issues.

 1) minicluster.ServerType added enum members

 Specifically TRACER and MONITOR. This changes the public API because
 ServerType is in it, and a client built against 1.6.2 could refer to
 these enum values and then get a NoSuchFieldError if they try to go back
 to 1.6.1. This only shows up as a low severity other issue in the
 1.6.1 - 1.6.2 check, which is probably why I didn't see it.

 2)
 core.client.mapreduce.AbstractInputFormat.getConfiguration(JobContext)
 changed from package-private to public

 This causes the method to show up as a new part of the public API. This
 issue only shows up in the 1.6.2 - 1.6.1 check below.


 Here are the specific report outputs for others to look:

 * 1.6.0 - 1.6.2 (added things are fine, because the change might be
 from 1.6.0 - 1.6.1)
 http://people.apache.org/~busbey/compat_reports/accumulo/1.6.0_to_1.6.2/
 compat_report.html
 * 1.6.1 - 1.6.2 (nothing should be added, but it's easier to just pay
 attention to the next one)
 http://people.apache.org/~busbey/compat_reports/accumulo/1.6.1_to_1.6.2/
 compat_report.html
 * 1.6.2 - 1.6.1 (under a semver patch increment, this should be just as
 strong an assertion as the reverse)
 http://people.apache.org/~busbey/compat_reports/accumulo/1.6.2_to_1.6.1/
 compat_report.html



 On Fri, Jan 23, 2015 at 8:02 PM, Corey Nolet cjno...@apache.org
 mailto:cjno...@apache.org wrote:

Devs,

  Please consider the following candidate for Apache Accumulo 1.6.2

  Branch: 1.6.2-rc2
  SHA1: 34987b4c8b4d896bbf2d26be8e70f70976614c0f
  Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1020/

  Source tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1020/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-src.tar.gz
  Binary tarball:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1020/org/apache/accumulo/accumulo/1.6.
 2/accumulo-1.6.2-bin.tar.gz
  (Append .sha1, .md5 or .asc to download the
 signature/hash for a given artifact.)

  Signing keys available at:
 https://www.apache.org/dist/accumulo/KEYS

  Over 1.6.1, we have 140 issues resolved
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob;f=CHANGES;h=26bdc0373cbbc26ef148db46c0a2cd638cb8c2b4;hb=1.6.2-rc2

  Testing: All unit, integration and functional tests are passing.

  The vote will be extended as a result of the weekend and will
 be open until Tuesday, January 28th 12:00AM UTC (1/27 8:00PM ET,
 1/27 5:00PM PT)




 --
 Sean

Re: [VOTE] Apache Accumulo 1.6.2 RC1

[Corey Nolet]

I'll add this to my docs for bugfix releases- thanks!

On Fri, Jan 23, 2015 at 1:05 AM, Sean Busbey bus...@cloudera.com wrote:

 Josh is correct, I used Java ACC.

 Our instructions are still present: *http://s.apache.org/ZrV
 http://s.apache.org/ZrV*


 On Thu, Jan 22, 2015 at 11:56 PM, Josh Elser josh.el...@gmail.com wrote:

  I think we used to have instruction lying around that described how to
 use
  https://github.com/lvc/japi-compliance-checker (not like that has any
  influence on what Sean used, though :D)
 
 
  Corey Nolet wrote:
 
  Sean- is this what you were using [1]?
 
  [1] https://java.net/projects/jascc
 
  On Thu, Jan 22, 2015 at 2:25 PM, Christopherctubb...@apache.org
 wrote:
 
   Various ITs timed out. I'll have to re-run on a more reliable machine.
 
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
  On Wed, Jan 21, 2015 at 7:50 PM, Corey Noletcjno...@gmail.com
 wrote:
 
   I did notice something strange reviewing this RC. It appears the
 
  staging
 
  repo doesn't have hash files for the detached GPG signatures
 
  (*.asc.md5,
 
  *.asc.sha1). That's new. Did you do something special regarding this,
  Corey? Or maybe this is just a change with mvn, or maybe it's a
 change
 
  with
 
  the staging repo? It's not an issue... the GPG signature doesn't need
 
  to
 
  also be hashed... it's just different and unexpected.
 
  I did update maven to the newest version. Other than that, I haven't
  done
  anything different int he release process.
 
   I could not complete a full build, because I had IT test timeouts
 with
  timeout.factor=2.
 
  Which IT tests were timing out for you?
 
  On Jan 21, 2015 6:22 PM, Christopherctubb...@apache.org  wrote:
 
   I did notice something strange reviewing this RC. It appears the
 
  staging
 
  repo doesn't have hash files for the detached GPG signatures
 
  (*.asc.md5,
 
  *.asc.sha1). That's new. Did you do something special regarding this,
  Corey? Or maybe this is just a change with mvn, or maybe it's a
 change
 
  with
 
  the staging repo? It's not an issue... the GPG signature doesn't need
 
  to
 
  also be hashed... it's just different and unexpected.
 
  Other checks I ran:
  GPG signatures on all the artifact files were good, so were the md5
 and
  sha1 hashes.
  Every jar artifact has a corresponding source/javadoc jar.
  The git commit matches that specified in the META-INF/MANIFEST.MF for
 
  each
 
  jar
  The lib directory contains the same jars as those signed/hashed.
  The branch matches the tag matches the source tarball contents.
 
  I could not complete a full build, because I had IT test timeouts
 with
  timeout.factor=2.
 
 
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
  On Wed, Jan 21, 2015 at 6:03 PM, Keith Turnerke...@deenlo.com
 
  wrote:
 
  I also ran the compliance checker tool.  The only other changes were
 
  in
 
  o.a.a.core.data.KeyValue.  But that class is not listed as part of
 
  public
 
  API.  The changes showed up in the report because the class was in
 
  data
 
  package.
 
  On Wed, Jan 21, 2015 at 6:01 PM, Christopherctubb...@apache.org
 
  wrote:
 
  On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbeybus...@cloudera.com
 
  wrote:
 
  On Wed, Jan 21, 2015 at 6:57 AM,dlmar...@comcast.net  wrote:
 
   I concur. This change makes the version of this release 1.7.0.
 
  We
 
  either
 
  need to change the version or remove the method. Good catch.
 
  Out
 
  of
 
  curiosity, did you find this by visual inspection or with a
 
  tool?
 
 
   While I have many eyes, they don't generally get spent on
 
  comprehensive
 
  code reviews. ;)
 
  I used the Java API Compatibility Checker.
 
 
 
   Was that the only violation?
 
  (Also, -1 for the same reason.)
 
 
 


 --
 Sean

Re: [VOTE] Apache Accumulo 1.6.2 RC1

[Corey Nolet]

Sean- is this what you were using [1]?

[1] https://java.net/projects/jascc

On Thu, Jan 22, 2015 at 2:25 PM, Christopher ctubb...@apache.org wrote:

 Various ITs timed out. I'll have to re-run on a more reliable machine.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Wed, Jan 21, 2015 at 7:50 PM, Corey Nolet cjno...@gmail.com wrote:

   I did notice something strange reviewing this RC. It appears the
 staging
   repo doesn't have hash files for the detached GPG signatures
 (*.asc.md5,
   *.asc.sha1). That's new. Did you do something special regarding this,
   Corey? Or maybe this is just a change with mvn, or maybe it's a change
  with
   the staging repo? It's not an issue... the GPG signature doesn't need
 to
   also be hashed... it's just different and unexpected.
 
  I did update maven to the newest version. Other than that, I haven't done
  anything different int he release process.
 
   I could not complete a full build, because I had IT test timeouts with
   timeout.factor=2.
 
  Which IT tests were timing out for you?
 
  On Jan 21, 2015 6:22 PM, Christopher ctubb...@apache.org wrote:
 
   I did notice something strange reviewing this RC. It appears the
 staging
   repo doesn't have hash files for the detached GPG signatures
 (*.asc.md5,
   *.asc.sha1). That's new. Did you do something special regarding this,
   Corey? Or maybe this is just a change with mvn, or maybe it's a change
  with
   the staging repo? It's not an issue... the GPG signature doesn't need
 to
   also be hashed... it's just different and unexpected.
  
   Other checks I ran:
   GPG signatures on all the artifact files were good, so were the md5 and
   sha1 hashes.
   Every jar artifact has a corresponding source/javadoc jar.
   The git commit matches that specified in the META-INF/MANIFEST.MF for
  each
   jar
   The lib directory contains the same jars as those signed/hashed.
   The branch matches the tag matches the source tarball contents.
  
   I could not complete a full build, because I had IT test timeouts with
   timeout.factor=2.
  
  
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
   On Wed, Jan 21, 2015 at 6:03 PM, Keith Turner ke...@deenlo.com
 wrote:
  
I also ran the compliance checker tool.  The only other changes were
 in
o.a.a.core.data.KeyValue.  But that class is not listed as part of
  public
API.  The changes showed up in the report because the class was in
 data
package.
   
On Wed, Jan 21, 2015 at 6:01 PM, Christopher ctubb...@apache.org
   wrote:
   
 On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey bus...@cloudera.com
 
wrote:

  On Wed, Jan 21, 2015 at 6:57 AM, dlmar...@comcast.net wrote:
 
   I concur. This change makes the version of this release 1.7.0.
 We
 either
   need to change the version or remove the method. Good catch.
 Out
  of
   curiosity, did you find this by visual inspection or with a
 tool?
  
  
  While I have many eyes, they don't generally get spent on
   comprehensive
  code reviews. ;)
 
  I used the Java API Compatibility Checker.
 
 
 
 Was that the only violation?

 (Also, -1 for the same reason.)

   
  
 

Re: [VOTE] Apache Accumulo 1.6.2 RC1

[Corey Nolet]

 I did notice something strange reviewing this RC. It appears the staging
 repo doesn't have hash files for the detached GPG signatures (*.asc.md5,
 *.asc.sha1). That's new. Did you do something special regarding this,
 Corey? Or maybe this is just a change with mvn, or maybe it's a change
with
 the staging repo? It's not an issue... the GPG signature doesn't need to
 also be hashed... it's just different and unexpected.

I did update maven to the newest version. Other than that, I haven't done
anything different int he release process.

 I could not complete a full build, because I had IT test timeouts with
 timeout.factor=2.

Which IT tests were timing out for you?

On Jan 21, 2015 6:22 PM, Christopher ctubb...@apache.org wrote:

 I did notice something strange reviewing this RC. It appears the staging
 repo doesn't have hash files for the detached GPG signatures (*.asc.md5,
 *.asc.sha1). That's new. Did you do something special regarding this,
 Corey? Or maybe this is just a change with mvn, or maybe it's a change with
 the staging repo? It's not an issue... the GPG signature doesn't need to
 also be hashed... it's just different and unexpected.

 Other checks I ran:
 GPG signatures on all the artifact files were good, so were the md5 and
 sha1 hashes.
 Every jar artifact has a corresponding source/javadoc jar.
 The git commit matches that specified in the META-INF/MANIFEST.MF for each
 jar
 The lib directory contains the same jars as those signed/hashed.
 The branch matches the tag matches the source tarball contents.

 I could not complete a full build, because I had IT test timeouts with
 timeout.factor=2.



 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Wed, Jan 21, 2015 at 6:03 PM, Keith Turner ke...@deenlo.com wrote:

  I also ran the compliance checker tool.  The only other changes were in
  o.a.a.core.data.KeyValue.  But that class is not listed as part of public
  API.  The changes showed up in the report because the class was in data
  package.
 
  On Wed, Jan 21, 2015 at 6:01 PM, Christopher ctubb...@apache.org
 wrote:
 
   On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey bus...@cloudera.com
  wrote:
  
On Wed, Jan 21, 2015 at 6:57 AM, dlmar...@comcast.net wrote:
   
 I concur. This change makes the version of this release 1.7.0. We
   either
 need to change the version or remove the method. Good catch. Out of
 curiosity, did you find this by visual inspection or with a tool?


While I have many eyes, they don't generally get spent on
 comprehensive
code reviews. ;)
   
I used the Java API Compatibility Checker.
   
   
   
   Was that the only violation?
  
   (Also, -1 for the same reason.)
  
 

Re: [VOTE] Apache Accumulo 1.6.2 RC1

[Corey Nolet]

-1

I think the compatibility tool should be run as standard procedure when
doing a bug fix release.
On Jan 21, 2015 2:10 PM, Keith Turner ke...@deenlo.com wrote:

 On Wed, Jan 21, 2015 at 3:08 AM, Sean Busbey bus...@cloudera.com wrote:

  -1
 
  The addition of
 
  org.apache.accumulo.minicluster
  MiniAccumuloConfig.useExistingInstance ( java.io.File accumuloSite,
  java.io.File hadoopConfDir )  *:*  MiniAccumuloConfig
 
  breaks our semver rules for a patch version increment because it adds
  backwards-compatible new functionality to the public API.
 

 nice catch

 -1


 
  On Tue, Jan 20, 2015 at 11:18 PM, Corey Nolet cjno...@apache.org
 wrote:
 
   Devs,
  
   Please consider the following candidate for Apache Accumulo 1.6.2
  
   Branch: 1.6.2-rc1
   SHA1: 533d93adb17e8b27c5243c97209796f66c6b8b2d
   Staging Repository:
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/
  
   Source tarball:
  
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
   Binary tarball:
  
  
 
 https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
   (Append .sha1, .md5 or .asc to download the signature/hash
 for
  a
   given artifact.)
  
   Signing keys available at:
 https://www.apache.org/dist/accumulo/KEYS
  
   Over 1.6.1, we have 136 issues resolved
  
  
 
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=CHANGES;h=925dd1380be94109cc1f85df7ce75f9c01d8b26d;hb=1.6.2-rc1
  
   Testing: All unit, integration and functional tests are passing.
  
   Vote will be open until Saturday, January 24th 12:00AM UTC (1/23
  8:00PM
   ET, 1/23 5:00PM PT)
  
 
 
 
  --
  Sean
 

[VOTE] Apache Accumulo 1.6.2 RC1

[Corey Nolet]

Devs,

Please consider the following candidate for Apache Accumulo 1.6.2

Branch: 1.6.2-rc1
SHA1: 533d93adb17e8b27c5243c97209796f66c6b8b2d
Staging Repository:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/

Source tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-src.tar.gz
Binary tarball:
https://repository.apache.org/content/repositories/orgapacheaccumulo-1018/org/apache/accumulo/accumulo/1.6.2/accumulo-1.6.2-bin.tar.gz
(Append .sha1, .md5 or .asc to download the signature/hash for a
given artifact.)

Signing keys available at: https://www.apache.org/dist/accumulo/KEYS

Over 1.6.1, we have 136 issues resolved
https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=CHANGES;h=925dd1380be94109cc1f85df7ce75f9c01d8b26d;hb=1.6.2-rc1

Testing: All unit, integration and functional tests are passing.

Vote will be open until Saturday, January 24th 12:00AM UTC (1/23 8:00PM
ET, 1/23 5:00PM PT)

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

 On Jan. 17, 2015, 1:08 a.m., Sean Busbey wrote:
  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex, line 
  584
  https://reviews.apache.org/r/29959/diff/3/?file=823376#file823376line584
 
  nit: you should say what an operator should expect to see from this 
  command when it's successful (nothing, IIRC) and maybe what it says if it 
  fails.

I was going to add a log statement so that the user could get some feedback but 
then I came across line 294 in the Initialize class. Were you at least able to 
see the Added volume volume log statement? Were you looking for something 
more descriptive?


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/#review68522
---


On Jan. 16, 2015, 5:06 a.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29959/
 ---
 
 (Updated Jan. 16, 2015, 5:06 a.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
 well as an error message when a replaced instance appears in instance.volumes
 
 
 Diffs
 -
 
   docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 
 4b917d1 
   server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
 51fa47e 
   server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
 e0a3797 
 
 Diff: https://reviews.apache.org/r/29959/diff/
 
 
 Testing
 ---
 
 Built the manual and found that the page numbers aren't aligning with the 
 table of contents. Opened up ACCUMULO-3486 to address this. Still need to 
 verify if it's a recent bug or if it's been around for awhile.
 
 Physically tested the error message appears when 'bin/accumulo init 
 --add-volumes' is called and a replaced volume appears in instance.volumes. 
 Also verified that the error does not appear when 'bin/accumulo init 
 --add-volumes' is called and the replaced volume does not appear in 
 instance.volumes
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/
---

(Updated Jan. 19, 2015, 6 p.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Repository: accumulo


Description
---

ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
well as an error message when a replaced instance appears in instance.volumes


Diffs (updated)
-

  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 4b917d1 
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
51fa47e 
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
e0a3797 

Diff: https://reviews.apache.org/r/29959/diff/


Testing
---

Built the manual and found that the page numbers aren't aligning with the table 
of contents. Opened up ACCUMULO-3486 to address this. Still need to verify if 
it's a recent bug or if it's been around for awhile.

Physically tested the error message appears when 'bin/accumulo init 
--add-volumes' is called and a replaced volume appears in instance.volumes. 
Also verified that the error does not appear when 'bin/accumulo init 
--add-volumes' is called and the replaced volume does not appear in 
instance.volumes


Thanks,

Corey Nolet

Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/
---

Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Repository: accumulo


Description
---

ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
well as an error message when a replaced instance appears in instance.volumes


Diffs
-

  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 4b917d1 
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
51fa47e 
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
e0a3797 

Diff: https://reviews.apache.org/r/29959/diff/


Testing
---

Built the manual and found that the page numbers aren't aligning with the table 
of contents. Opened up ACCUMULO-3486 to address this. Still need to verify if 
it's a recent bug or if it's been around for awhile.

Physically tested the error message appears when 'bin/accumulo init 
--add-volumes' is called and a replaced volume appears in instance.volumes. 
Also verified that the error does not appear when 'bin/accumulo init 
--add-volumes' is called and the replaced volume does not appear in 
instance.volumes


Thanks,

Corey Nolet

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/#review68408
---



server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java
https://reviews.apache.org/r/29959/#comment112605

Just noticed this. We should certainly have the conversation to standardize 
on this. I don't mind doing what everyone's been doing, I just need to know 
what that is.


- Corey Nolet


On Jan. 16, 2015, 4:37 a.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29959/
 ---
 
 (Updated Jan. 16, 2015, 4:37 a.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
 well as an error message when a replaced instance appears in instance.volumes
 
 
 Diffs
 -
 
   docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 
 4b917d1 
   server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
 51fa47e 
   server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
 e0a3797 
 
 Diff: https://reviews.apache.org/r/29959/diff/
 
 
 Testing
 ---
 
 Built the manual and found that the page numbers aren't aligning with the 
 table of contents. Opened up ACCUMULO-3486 to address this. Still need to 
 verify if it's a recent bug or if it's been around for awhile.
 
 Physically tested the error message appears when 'bin/accumulo init 
 --add-volumes' is called and a replaced volume appears in instance.volumes. 
 Also verified that the error does not appear when 'bin/accumulo init 
 --add-volumes' is called and the replaced volume does not appear in 
 instance.volumes
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

 On Jan. 16, 2015, 4:57 a.m., Josh Elser wrote:
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java, 
  line 39
  https://reviews.apache.org/r/29959/diff/1/?file=823371#file823371line39
 
  Unnecessary change?

You are right- originally I had the error log in this class but then I moved 
it. I'll remove this.


 On Jan. 16, 2015, 4:57 a.m., Josh Elser wrote:
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java, 
  line 506
  https://reviews.apache.org/r/29959/diff/1/?file=823372#file823372line506
 
  Unnecessary change?

This happened when I ran the formatter.


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/#review68407
---


On Jan. 16, 2015, 4:37 a.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29959/
 ---
 
 (Updated Jan. 16, 2015, 4:37 a.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
 well as an error message when a replaced instance appears in instance.volumes
 
 
 Diffs
 -
 
   docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 
 4b917d1 
   server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
 51fa47e 
   server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
 e0a3797 
 
 Diff: https://reviews.apache.org/r/29959/diff/
 
 
 Testing
 ---
 
 Built the manual and found that the page numbers aren't aligning with the 
 table of contents. Opened up ACCUMULO-3486 to address this. Still need to 
 verify if it's a recent bug or if it's been around for awhile.
 
 Physically tested the error message appears when 'bin/accumulo init 
 --add-volumes' is called and a replaced volume appears in instance.volumes. 
 Also verified that the error does not appear when 'bin/accumulo init 
 --add-volumes' is called and the replaced volume does not appear in 
 instance.volumes
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/
---

(Updated Jan. 16, 2015, 5:03 a.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Repository: accumulo


Description
---

ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
well as an error message when a replaced instance appears in instance.volumes


Diffs (updated)
-

  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 4b917d1 
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
51fa47e 
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
e0a3797 

Diff: https://reviews.apache.org/r/29959/diff/


Testing
---

Built the manual and found that the page numbers aren't aligning with the table 
of contents. Opened up ACCUMULO-3486 to address this. Still need to verify if 
it's a recent bug or if it's been around for awhile.

Physically tested the error message appears when 'bin/accumulo init 
--add-volumes' is called and a replaced volume appears in instance.volumes. 
Also verified that the error does not appear when 'bin/accumulo init 
--add-volumes' is called and the replaced volume does not appear in 
instance.volumes


Thanks,

Corey Nolet

Re: Review Request 29959: ACCUMULO-2793 Adding non-HA to HA migration info to user manual and log error when improperly configuring instance.volumes.

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29959/
---

(Updated Jan. 16, 2015, 5:06 a.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Repository: accumulo


Description
---

ACCUMULO-2793 Adding info to user manual about migration from non-HA to HA as 
well as an error message when a replaced instance appears in instance.volumes


Diffs (updated)
-

  docs/src/main/latex/accumulo_user_manual/chapters/administration.tex 4b917d1 
  server/base/src/main/java/org/apache/accumulo/server/ServerConstants.java 
51fa47e 
  server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java 
e0a3797 

Diff: https://reviews.apache.org/r/29959/diff/


Testing
---

Built the manual and found that the page numbers aren't aligning with the table 
of contents. Opened up ACCUMULO-3486 to address this. Still need to verify if 
it's a recent bug or if it's been around for awhile.

Physically tested the error message appears when 'bin/accumulo init 
--add-volumes' is called and a replaced volume appears in instance.volumes. 
Also verified that the error does not appear when 'bin/accumulo init 
--add-volumes' is called and the replaced volume does not appear in 
instance.volumes


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Jan. 9, 2015, 3:11 a.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Bugs: ACCUMULO-3458
https://issues.apache.org/jira/browse/ACCUMULO-3458


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
666a8af 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
9726266 
  
core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
 2a79f05 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  core/src/test/java/org/apache/accumulo/core/client/impl/ScannerImplTest.java 
be4d467 
  
core/src/test/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderTest.java
 PRE-CREATION 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
 bf35557 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

 On Jan. 1, 2015, 12:36 a.m., kturner wrote:
  core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java,
   line 78
  https://reviews.apache.org/r/29502/diff/2/?file=804700#file804700line78
 
  was putting @Override on same line as method decleration intentional?
 
 Christopher Tubbs wrote:
 Probably best to just format and organize imports for all the changed 
 files. I noticed a lot of other formatting issues, too.
 
 Corey Nolet wrote:
 Not sure why intelli-j defaults to this behavior but it's fixed.
 
 Christopher Tubbs wrote:
 Import order is something that our formatting standards don't even 
 address, I just noticed the change and thought it unusual.

This is something we worked out on Fluo early on and I believe the static 
changing from the top of the imports to the bottom was a result of that- though 
I'm surprised, unless Keith has multiple profiles for his import orders, why we 
wouldn't have noticed this sooner in his patches.

See https://github.com/fluo-io/fluo/wiki/Contributing#coding-guidelines


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/#review66493
---


On Jan. 6, 2015, 3:54 p.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29502/
 ---
 
 (Updated Jan. 6, 2015, 3:54 p.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Bugs: ACCUMULO-3458
 https://issues.apache.org/jira/browse/ACCUMULO-3458
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-3458 Propagating scan-time authorizations through the 
 IteratorEnvironment so that scan-time iterators can use them.
 
 
 Diffs
 -
 
   
 core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
  4903656 
   core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
   core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
 2552682 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
 666a8af 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
 9726266 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
  2a79f05 
   
 core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
 72cb863 
   
 core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java
  9e20cb1 
   
 core/src/test/java/org/apache/accumulo/core/client/impl/ScannerImplTest.java 
 be4d467 
   
 core/src/test/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderTest.java
  PRE-CREATION 
   
 core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
  94da7b5 
   
 core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
  fa46360 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
  4521e55 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
  4cebab7 
   
 server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
  4a45e99 
   
 server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
  a9801b0 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
  bf35557 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
  d1fece5 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java
  869cc33 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
  fe4b16b 
   test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
 PRE-CREATION 
   test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/29502/diff/
 
 
 Testing
 ---
 
 Wrote an integration test to verify that ScanDataSource is actually setting 
 the authorizations on the IteratorEnvironment
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

 On Jan. 5, 2015, 9:09 p.m., Christopher Tubbs wrote:
  core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java,
   line 63
  https://reviews.apache.org/r/29502/diff/2/?file=804705#file804705line63
 
  Should this be Authorizations.EMPTY? Or should it have a default 
  implementation on WrappingIterator which calls source.getAuthorizations()?
 
 Christopher Tubbs wrote:
 make that `getSource().getAuthorizations()`

Specific to this test I returned null because all the other getters (other than 
what was being explicitly tested) were returning null. Were you thinking 
WrappingIterator should also provide a getAuthorizations() method?


 On Jan. 5, 2015, 9:09 p.m., Christopher Tubbs wrote:
  server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java,
   line 46
  https://reviews.apache.org/r/29502/diff/2/?file=804711#file804711line46
 
  I wonder if there's a better way to provide environment options, like 
  this and others, at specific scopes. Maybe use some dependency injection, 
  with annotations, like Servlet @Context or JUnit @Rule: @ScanContext 
  Authorizations auths; (throw error if type is not appropriate for context 
  during injection).

This feature would be pretty neat. Were you thinking this would extend past 
just the IteratorEnvironment into other places? Any other fields you can think 
of that would benefit from this change other than Authorizations?


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/#review66725
---


On Dec. 31, 2014, 3:40 p.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29502/
 ---
 
 (Updated Dec. 31, 2014, 3:40 p.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Bugs: ACCUMULO-3458
 https://issues.apache.org/jira/browse/ACCUMULO-3458
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-3458 Propagating scan-time authorizations through the 
 IteratorEnvironment so that scan-time iterators can use them.
 
 
 Diffs
 -
 
   
 core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
  4903656 
   core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
   core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
 2552682 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
 666a8af 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
 9726266 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
  2a79f05 
   
 core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
 72cb863 
   
 core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java
  9e20cb1 
   
 core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
  15c33fa 
   
 core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
  94da7b5 
   
 core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
  fa46360 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
  4521e55 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
  4cebab7 
   
 server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
  4a45e99 
   
 server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
  a9801b0 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
  bf35557 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
  d1fece5 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java
  869cc33 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
  fe4b16b 
   test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
 PRE-CREATION 
   test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/29502/diff/
 
 
 Testing
 ---
 
 Wrote an integration test to verify that ScanDataSource is actually setting 
 the authorizations on the IteratorEnvironment
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Jan. 6, 2015, 3:44 p.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Changes
---

Fixed based on feedback from Christopher and Keith. Noticed some extra 
formatting removing whitespace in some places.


Bugs: ACCUMULO-3458
https://issues.apache.org/jira/browse/ACCUMULO-3458


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs (updated)
-

  core/src/main/java/org/apache/accumulo/core/client/BatchDeleter.java 2bfc347 
  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/Scanner.java 112179e 
  core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
666a8af 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerIterator.java 
1e0ac99 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
9726266 
  
core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
 2a79f05 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  core/src/main/java/org/apache/accumulo/core/iterators/WrappingIterator.java 
060fa76 
  
core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
 15c33fa 
  core/src/test/java/org/apache/accumulo/core/client/impl/ScannerImplTest.java 
be4d467 
  
core/src/test/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderTest.java
 PRE-CREATION 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
 bf35557 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Jan. 6, 2015, 3:54 p.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Changes
---

Removing files which were formatted but not changed in any other way to augment 
the feature in the commit.


Bugs: ACCUMULO-3458
https://issues.apache.org/jira/browse/ACCUMULO-3458


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
666a8af 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
9726266 
  
core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
 2a79f05 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  core/src/test/java/org/apache/accumulo/core/client/impl/ScannerImplTest.java 
be4d467 
  
core/src/test/java/org/apache/accumulo/core/client/impl/TabletServerBatchReaderTest.java
 PRE-CREATION 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
 bf35557 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Dec. 31, 2014, 1:46 p.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs (updated)
-

  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
666a8af 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
9726266 
  
core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
 2a79f05 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  
core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
 15c33fa 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
 bf35557 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

 On Dec. 31, 2014, 4:30 a.m., Josh Elser wrote:
  core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java,
   line 197
  https://reviews.apache.org/r/29502/diff/1/?file=804415#file804415line197
 
  Can't you pull this from the Scanner?

I didn't see a good way to get this info from the scanner. The more I think 
about this- a simple getter on the scanner would be massively useful.


 On Dec. 31, 2014, 4:30 a.m., Josh Elser wrote:
  server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java,
   line 55
  https://reviews.apache.org/r/29502/diff/1/?file=804426#file804426line55
 
  It looks like TabletIteratorEnvironment is used for minor compactions. 
  Isn't always setting `Authorizations.EMPTY` a little misleading? Is there 
  something more representative of having all auths we could do here? Maybe 
  extra documentation is enough? Could also throw 
  UnsupportedOperationException or similar when the IteratorScope is 
  something that isn't SCAN?

Good point! This should definitely be documented as a scan-time only operation. 
I'm on the fence about throwing an exception- I think I could go either way on 
that.


 On Dec. 31, 2014, 4:30 a.m., Josh Elser wrote:
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java, line 54
  https://reviews.apache.org/r/29502/diff/1/?file=804430#file804430line54
 
  Please create a user, assign it the auths you need, and then remove the 
  user after the test.
  
  If this test is run against a standalone instance, it should try to 
  leave the system in the same state the test started in.

You know I was thinking about this when I was coding the test and totally 
forgot to change it before I created the patch.


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/#review66439
---


On Dec. 31, 2014, 1:46 p.m., Corey Nolet wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/29502/
 ---
 
 (Updated Dec. 31, 2014, 1:46 p.m.)
 
 
 Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
 kturner.
 
 
 Repository: accumulo
 
 
 Description
 ---
 
 ACCUMULO-3458 Propagating scan-time authorizations through the 
 IteratorEnvironment so that scan-time iterators can use them.
 
 
 Diffs
 -
 
   
 core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
  4903656 
   core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
   core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
 2552682 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
 666a8af 
   core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
 9726266 
   
 core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
  2a79f05 
   
 core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
 72cb863 
   
 core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java
  9e20cb1 
   
 core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
  15c33fa 
   
 core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
  94da7b5 
   
 core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
  fa46360 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
  4521e55 
   
 core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
  4cebab7 
   
 server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
  4a45e99 
   
 server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
  a9801b0 
   
 server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
  bf35557 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
  d1fece5 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java
  869cc33 
   
 server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
  fe4b16b 
   test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
 PRE-CREATION 
   test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/29502/diff/
 
 
 Testing
 ---
 
 Wrote an integration test to verify that ScanDataSource is actually setting 
 the authorizations on the IteratorEnvironment
 
 
 Thanks,
 
 Corey Nolet
 

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Dec. 31, 2014, 10:40 a.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Bugs: ACCUMULO-3458
https://issues.apache.org/jira/browse/ACCUMULO-3458


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs
-

  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/ScannerBase.java 335b63a 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerImpl.java 
666a8af 
  core/src/main/java/org/apache/accumulo/core/client/impl/ScannerOptions.java 
9726266 
  
core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchReader.java
 2a79f05 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  
core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
 15c33fa 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/monitor/src/main/java/org/apache/accumulo/monitor/servlets/trace/NullScanner.java
 bf35557 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: Review Request 29502: ACCUMULO-3458 Adding scan authorizations to IteratorEnvironment

[Corey Nolet]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29502/
---

(Updated Dec. 31, 2014, 4:05 a.m.)


Review request for accumulo, Christopher Tubbs, Eric Newton, Josh Elser, and 
kturner.


Changes
---

Added accumulo group to review.


Repository: accumulo


Description
---

ACCUMULO-3458 Propagating scan-time authorizations through the 
IteratorEnvironment so that scan-time iterators can use them.


Diffs
-

  
core/src/main/java/org/apache/accumulo/core/client/ClientSideIteratorScanner.java
 4903656 
  core/src/main/java/org/apache/accumulo/core/client/impl/OfflineScanner.java 
2552682 
  core/src/main/java/org/apache/accumulo/core/client/mock/MockScannerBase.java 
72cb863 
  
core/src/main/java/org/apache/accumulo/core/iterators/IteratorEnvironment.java 
9e20cb1 
  
core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
 15c33fa 
  
core/src/test/java/org/apache/accumulo/core/iterators/DefaultIteratorEnvironment.java
 94da7b5 
  
core/src/test/java/org/apache/accumulo/core/iterators/FirstEntryInRowIteratorTest.java
 fa46360 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/RowDeletingIteratorTest.java
 4521e55 
  
core/src/test/java/org/apache/accumulo/core/iterators/user/TransformingIteratorTest.java
 4cebab7 
  
server/base/src/test/java/org/apache/accumulo/server/iterators/MetadataBulkLoadFilterTest.java
 4a45e99 
  
server/base/src/test/java/org/apache/accumulo/server/replication/StatusCombinerTest.java
 a9801b0 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/TabletIteratorEnvironment.java
 d1fece5 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Compactor.java 
869cc33 
  
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/ScanDataSource.java
 fe4b16b 
  test/src/main/java/org/apache/accumulo/test/functional/AuthsIterator.java 
PRE-CREATION 
  test/src/test/java/org/apache/accumulo/test/ScanIteratorIT.java PRE-CREATION 

Diff: https://reviews.apache.org/r/29502/diff/


Testing
---

Wrote an integration test to verify that ScanDataSource is actually setting the 
authorizations on the IteratorEnvironment


Thanks,

Corey Nolet

Re: JIRA Tickets for 1.6.2 Release

[Corey Nolet]

 Have you started tracking a CHANGES list yet (do we need to update
anything added back in 1.6.2)?

I did start a CHANGES file in the 1.6.2-SNAPSHOT branch. I figure after the
tickets settle down I'll just create a new one.

On Thu, Dec 18, 2014 at 2:05 PM, Christopher ctubb...@apache.org wrote:

 I triage'd some of the issues, deferring to 1.7 if they were marked with a
 fixVersion of 1.5.x or 1.6.x. I left documentation issues alone, as well as
 tests-related improvements and tasks. I commented on a few which looked
 like they were general internal improvements that weren't necessarily bugs.
 Feel free to change them to bugs if I make an incorrect choice on those.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Dec 18, 2014 at 1:06 PM, Josh Elser josh.el...@gmail.com wrote:
 
  Thanks for starting this up, Corey. Have you started tracking a CHANGES
  list yet (do we need to update anything added back in 1.6.2)?
 
  Oof, good point re semver. Let's coordinate on triaging the tickets as
  there are quite a few. On IRC? I don't want multiple people to spend time
  looking at the same issues :)
 
 
  Christopher wrote:
 
  Because we've agreed on Semver for release versioning, all the JIRAs
  marked
  for 1.6.x as something other than Bug (or maybe Task, and Test)
  should probably have 1.6.x dropped from their fixVersion.
 
  They can/should get addressed in 1.7 and later. Those currently marked
 for
  1.6.x need to be triage'd to determine if they've been labeled
 correctly,
  though.
 
  It's not that we can't improve internals in a patch release with Semver
  (so
  long as we don't alter the API)... but Semver helps focus changes to
 patch
  releases on things that fix buggy behavior.
 
  I'll do some triage later today (after some sleep) if others haven't
  gotten
  to it first.
 
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
  On Thu, Dec 18, 2014 at 12:44 AM, Corey Noletcjno...@gmail.com
 wrote:
 
  Since we've been discussing cutting an rc0 for testing before we begin
  the
  formal release process. I've moved over all the non-blocker tickets
 from
  1.6.2 to 1.6.3 [1]. Many of the tickets that moved haven't been updated
  since the 1.6.1 release. If there are tickets you feel are necessary
 for
  1.6.2, feel free to move them back and mark them as a blocker [2]. I'd
  like
  to get an rc0 out very soon- possibly in the next couple of days.
 
  [1]
 
  https://issues.apache.org/jira/issues/?jql=project%20%
  3D%20ACCUMULO%20AND%20fixVersion%20%3D%201.6.3
 
  [2]
 
  https://issues.apache.org/jira/issues/?jql=project%20%
  3D%20Accumulo%20and%20priority%20%3D%20Blocker%
  20and%20fixVersion%20%3D%201.6.2%20and%20status%20%3D%20Open
 
 
 

Re: 1.6.2 candidates

[Corey Nolet]

I'll cut one tonight

On Wed, Dec 17, 2014 at 1:52 PM, Christopher ctubb...@apache.org wrote:

 I think we could probably put together a non-voting RC0 to start testing
 with.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Tue, Dec 16, 2014 at 11:28 PM, Eric Newton eric.new...@gmail.com
 wrote:
 
  We are running 1.6.1 w/patches in production already.  I would much
 rather
  have a 1.6.2 official release.
 
  I may have temporary access to a small cluster (3-ish racks) to run some
 of
  the long running tests on bare metal.
 
  Testing sooner, rather than later is preferable.
 
 
 
 
  On Tue, Dec 16, 2014 at 7:18 PM, Corey Nolet cjno...@gmail.com wrote:
  
   I have cycles to spin the RCs- I wouldn't mind finishing the updates
 (per
   my notes) of the release documentation as well.
  
   On Tue, Dec 16, 2014 at 7:11 PM, Christopher ctubb...@apache.org
  wrote:
   
I think it'd be good to let somebody else exercise the process a bit,
   but I
can make the RCs if nobody else volunteers. My primary concern is
 that
people will have time to test.
   
   
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
   
On Tue, Dec 16, 2014 at 6:37 PM, Josh Elser josh.el...@gmail.com
   wrote:

 +1 There are lots of good bug fixes in 1.6.2 already.

 I can make some time to test, document, etc. Are you volunteering
 to
   spin
 the RCs as well?


 Christopher wrote:

 I'm thinking we should look at releasing 1.6.2 in January. I'd say
sooner,
 but I don't know if people will have time to test if we start
  putting
 together RCs this week or next.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


   
  
 

JIRA Tickets for 1.6.2 Release

[Corey Nolet]

Since we've been discussing cutting an rc0 for testing before we begin the
formal release process. I've moved over all the non-blocker tickets from
1.6.2 to 1.6.3 [1]. Many of the tickets that moved haven't been updated
since the 1.6.1 release. If there are tickets you feel are necessary for
1.6.2, feel free to move them back and mark them as a blocker [2]. I'd like
to get an rc0 out very soon- possibly in the next couple of days.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ACCUMULO%20AND%20fixVersion%20%3D%201.6.3

[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20Accumulo%20and%20priority%20%3D%20Blocker%20and%20fixVersion%20%3D%201.6.2%20and%20status%20%3D%20Open

build.sh script still being used?

[Corey Nolet]

I'm working on updating the Making a Release page on our website [1] with
more detailed instructions on the steps involved. Create the candidate
section references the build.sh script and I'm contemplating just removing
it altogether since it seems like, after quick discussions with a few
individuals, maven is mostly being called directly. I don't want to remove
this, however, if there are others in the community who still feel it is
necessary.

The commands that are present in the script are going to be well documented
on the page already. Do we need to keep the script around?


[1] http://accumulo.apache.org/releasing.html

Re: 1.6.2 candidates

[Corey Nolet]

I have cycles to spin the RCs- I wouldn't mind finishing the updates (per
my notes) of the release documentation as well.

On Tue, Dec 16, 2014 at 7:11 PM, Christopher ctubb...@apache.org wrote:

 I think it'd be good to let somebody else exercise the process a bit, but I
 can make the RCs if nobody else volunteers. My primary concern is that
 people will have time to test.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Tue, Dec 16, 2014 at 6:37 PM, Josh Elser josh.el...@gmail.com wrote:
 
  +1 There are lots of good bug fixes in 1.6.2 already.
 
  I can make some time to test, document, etc. Are you volunteering to spin
  the RCs as well?
 
 
  Christopher wrote:
 
  I'm thinking we should look at releasing 1.6.2 in January. I'd say
 sooner,
  but I don't know if people will have time to test if we start putting
  together RCs this week or next.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 

Re: accumulo join order count,sum,avg

[Corey Nolet]

A good example of the count/sum/average can be found in our StatsCombiner
example [1]. Joins are a complicated one- your implementation of joins will
really depend on your data set and the expected sizes of each side of the
join. You can obviously always resort to joining data together on different
tablets using Mapreduce or Spark but you may be able to simulate more
real-time joins if your data allows. Ordering is kind of the same here-
depending on your data, you could use specialized indexes that take
advantage of the Accumulo keys already being sorted.

If you can provide some more detail about your data set, we may be able to
provide more specific examples on how to accomplish this.




[1]  https://accumulo.apache.org/1.6/examples/combiner.html

On Sun, Dec 14, 2014 at 9:02 PM, panqing...@163.com panqing...@163.com
wrote:

 Accumulo implementation of the join order count sum AVG how to achieve
 this?



 --
 View this message in context:
 http://apache-accumulo.1065345.n5.nabble.com/accumulo-join-order-count-sum-avg-tp12568.html
 Sent from the Developers mailing list archive at Nabble.com.

Re: accumulo Scanner

[Corey Nolet]

You're going to want to use WholeRowIterator.decodeRow(entry.getKey(),
entry.getValue()) for that one. You can do:

for(EntryKey,Value entry : scanner) {
   for(EntryKey,Value actualEntry :
WholeRowIterator.decodeRow(entry.getKey(), entry.getValue()).entrySet()) {
// do something with actualEntry
   }
}

On Thu, Dec 11, 2014 at 10:24 PM, panqing...@163.com panqing...@163.com
wrote:

 I try to use the WholeRowIterator, the same rowkey data into a line, Now,
 Value contains ColumnFamily, ColumnQualifier, value，but the value of Value
 should be how to analysis?

  for (EntryKey, Value entry : scanner) {
 log.info( + entry.getKey() + , + entry.getValue());
 }




 --
 View this message in context:
 http://apache-accumulo.1065345.n5.nabble.com/accumulo-Scanner-tp12506p12552.html
 Sent from the Developers mailing list archive at Nabble.com.

Re: Accumulo Working Day

[Corey Nolet]

Also talked a little about Christopher's working on a new API design:
https://github.com/ctubbsii/accumulo/blob/ACCUMULO-2589/

On Tue, Dec 9, 2014 at 11:56 PM, Josh Elser josh.el...@gmail.com wrote:

 Just so you don't think I forgot, there wasn't really much to report
 today. Lots of friendly banter among everyone.

 The notable discussion was likely Don Miner stopping by and the collective
 trying to brainstorm suggestions as to who would be a good candidate for a
 high-profile keynote speaker for Accumulo Summit 2015 :)

 We also talked a little bit about metrics (with the recent support for
 Hadoop metrics2 added) which helped bring some other devs up to speed who
 hadn't looked at what such support really means.

 Let me know if I forgot anything other attendees.


 Josh Elser wrote:

 I'd be happy to. Not too much discussion yet, but if we talk about
 anything that doesn't end up on JIRA or elsewhere, I'll make sure it
 gets posted here.

 - Josh

 Mike Drob wrote:

 For those of us who were unable to attend, can we get a summary of what
 happened? I'd be curious to know if anything particularly novel came
 out of
 this collaboration!

 On Mon, Dec 8, 2014 at 4:06 PM, Jason Pyeronjpye...@pdinc.us wrote:

  If you are meeting near Ft. Meade I would like to drop off thank you
 doughnuts.

 -Jason

  -Original Message-
 From: Keith Turner
 Sent: Wednesday, December 03, 2014 14:00

 Christopher, Eric, Josh, Billie, Mike, and I are meeting on
 Dec 9 to work
 on Accumulo together for the day in Central MD. If you are
 interested in
 joining us, email me directly. We are meeting in a small
 conf room, so
 space is limited.

 Keith

  --
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 - -
 - Jason Pyeron PD Inc. http://www.pdinc.us -
 - Principal Consultant 10 West 24th Street #100 -
 - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
 - -
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 This message is copyright PD Inc, subject to license 20080407P00.

Re: [VOTE] ACCUMULO-3176

[Corey Nolet]

+1 in case it wasn't inferred from my previous comments. As Josh stated,
I'm still confused how the veto still holds technical justification- the
changes being made aren't removing methods from the public API.

On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser josh.el...@gmail.com wrote:

 I still don't understand what could even be changed to help you retract
 your veto.

 A number of people here have made suggestions about altering the changes
 to the public API WRT to the major version. I think Brian was the most
 recent, but I recall asking the same question on the original JIRA issue
 too.


 Sean Busbey wrote:

 I'm not sure what questions weren't previously answered in my
 explanations,
 could you please restate which ever ones you want clarification on?

 The vote is closed and only has 2 binding +1s. That means it fails under
 consensus rules regardless of my veto, so the issue seems moot.

 On Mon, Dec 1, 2014 at 1:59 PM, Christopherctubb...@apache.org  wrote:

  So, it's been 5 days since last activity here, and there are still some
 questions/requests for response left unanswered regarding the veto. I'd
 really like a response to these questions so we can put this issue to
 rest.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Wed, Nov 26, 2014 at 1:21 PM, Christopherctubb...@apache.org
 wrote:

  On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbeybus...@cloudera.com

 wrote:

 Responses to a few things below.


 On Tue, Nov 25, 2014 at 2:56 PM, Brian Lossbfl...@praxiseng.com

 wrote:

 Aren’t API-breaking changes allowed in 1.7? If this change is ok for

 2.0,

 then what is the technical reason why it is ok for version 2.0 but

 vetoed

 for version 1.7?

  On Nov 25, 2014, at 3:48 PM, Sean Busbeybus...@cloudera.com

 wrote:


 How about if we push this change in the API out to the client

 reworking

 in

 2.0? Everything will break there anyways so users will already have

 to

 deal

 with the change.

 As I previously mentioned, API breaking changes are allowed on major
 revisions. Currently, 1.7 is a major revision (and I have consistently
 argued for it to remain classified as such). That doesn't mean we
 shouldn't
 consider the cost to end users of making said changes.

 There is no way to know that there won't be a 1.8 or later version
 after
 1.7 and before 2.0. We already have consensus to do a sweeping overhaul

 of

 the API for that later release and have had that consensus for quite

 some

 time. Since users will already have to deal with that breakage in 2.0 I
 don't see this improvement as worth making them deal with changes prior

 to

 that.


  So, are you arguing for no more API additions until 2.0? Because,
 that's
 what it sounds like. As is, your general objection to the API seems to
 be
 independent of this change, but reflective of an overall policy for API
 additions. Please address why your argument applies to this specific
 change, and wouldn't to other API additions. Otherwise, this seems to be

 a

 case of special pleading.

 Please address the fact that there is no breakage here, and we can
 ensure
 that there won't be any more removal (except in exceptional

 circumstances)

 of deprecated APIs until 2.0 to ease changes. (I actually think that

 would

 be a very reasonable policy to adopt today.) In addition, I fully expect
 that 2.0 will be fully compatible with 1.7, and will also not introduce

 any

 breakage except removal of things already deprecated in 1.7. If we make
 this change without marking the previous createTable methods as

 deprecated,

 this new API addition AND the previous createTable API will still be
 available in 2.0 (as deprecated), and will not be removed until 3.0.

 You have also previously argued for more intermediate releases between
 major releases. Please explain how you see omitting this API addition is
 compatible with that goal. Please also explain why, if you consider 1.7

 to

 be a major (expected) release, why such an addition would not be
 appropriate, but would be appropriate for a future major release (2.0).


  On Tue, Nov 25, 2014 at 4:18 PM, Christopherctubb...@apache.org

 wrote:

 On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki

 bhava...@clouderagovt.com

 wrote:

  In my interpretation of Sean's veto, what he says is bad - using the

 ASF

 word here - is not that the change leaves the property update

 unsolved.

 It's that it changes the API without completely solving it. The

 purpose

 of

 the change is not explicitly to alter the API, but it does cause

 that

 to

 happen, and it is that aspect that is bad (with the given

 justification).

 I just want to clarify my reasoning.

 That is my current understanding, as well. Additionally, it seems to

 me

 that the two things that make it bad is that it A) doesn't achieve

 an

 additional purpose (which can be achieved with additional work), and

 that

 B) it deprecates existing methods (which can be avoided). Unless

 there's

 some other reason that 

Re: [DISCUSS] Bylaws Change - Majority Approval for Code Changes

[Corey Nolet]

Jeremy,

The PMC boards in ASF are re

On Wed, Nov 26, 2014 at 1:18 PM, Jeremy Kepner kep...@ll.mit.edu wrote:

 To be effective, most boards need to be small (~5 people) and not involved
 with day-to-day.
 Ideally, if someone says let's bring this to the board for a decision the
 collective response should be no, let's figure out a compromise.

 On Wed, Nov 26, 2014 at 12:26:09PM -0600, Mike Drob wrote:
  Jeremey, FWIW I believe that the PMC is supposed to be that board. In our
  case, it happens to also be the same population as the committers,
 because
  it was suggested that the overlap leads to a healthier community overall.
 
  On Wed, Nov 26, 2014 at 12:02 PM, Jeremy Kepner kep...@ll.mit.edu
 wrote:
 
   -1 (I vote to keep current consensus approach)
  
   An alternative method for resolution would be to setup an
   elected (or appointed) advisory board of a small number of folks whose
   job it is to look out for the long-term health and strategy of
 Accumulo.
   This board could then
   be appealed to on the rare occassions when consensus over important
   long-term issues
   cannot be achieved.  Just the presence of such a board often has the
 effect
   encouraging productive compromise amongst participants.
  
  
  
   On Wed, Nov 26, 2014 at 05:33:40PM +, dlmar...@comcast.net wrote:
   
It was suggested in the ACCUMULO-3176 thread that code changes
 should be
   majority approval instead of consensus approval. I'd like to explore
 this
   idea as it might keep the voting email threads less verbose and leave
 the
   discussion and consensus building to the comments in JIRA. Thoughts?
  

Re: [VOTE] ACCUMULO-3176

[Corey Nolet]

 I could understand the veto if the change actually caused one of the
issues mentioned above or the issue that Sean is raising. But it does not.
The eventual consistency of property updates was an issue before this
change and continues to be an issue. This JIRA did not attempt to address
the property update issue.

You said this before I could and I couldn't agree more.

 Everything will break there anyways so users will already have to deal
with the change.

I didn't see any methods removed from the API but I could be missing
something. I just see a new create() method added.


On Tue, Nov 25, 2014 at 3:56 PM, Brian Loss bfl...@praxiseng.com wrote:

 Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0,
 then what is the technical reason why it is ok for version 2.0 but vetoed
 for version 1.7?

  On Nov 25, 2014, at 3:48 PM, Sean Busbey bus...@cloudera.com wrote:
 
 
  How about if we push this change in the API out to the client reworking
 in
  2.0? Everything will break there anyways so users will already have to
 deal
  with the change.
 
  --
  Sean

Re: Contribute Examples/Exercises

[Corey Nolet]

Mike  David,

Are you +1 for contributing the examples or +1 for moving the examples out
into separate repos?

On Fri, Nov 14, 2014 at 12:52 PM, David Medinets david.medin...@gmail.com
wrote:

 +1
 On Nov 14, 2014 11:18 AM, Keith Turner ke...@deenlo.com wrote:

  On Wed, Nov 12, 2014 at 4:52 PM, Corey Nolet cjno...@gmail.com wrote:
 
   Josh,
  
My worry with a contrib module is that, historically, code which goes
   moves to a contrib is just one step away from the grave.
  
   You do have a good point. My hope was that this could be the beginning
 of
   our changing history so that we could begin to encourage the community
 to
   contribute their own source directly and give them an outlet for doing
  so.
   I understand that's also the intent of hosting open source repos under
  ASF
   to begin with- so I'm partial to either outcome.
  
I think there's precedence for keeping them in core (as Christopher
 had
   mentioned, next to examples/simple) which would benefit people
 externally
   (more how do I do X examples) and internally (keep devs honest about
  how
   our APIs are implemented).
  
   I would think that would just require keeping the repos up to date as
   versions change so they wouldn't get out of date and possibly releasing
   them w/ our other releases.
  
  
   Wherever they end up living, thank you Adam for the contributions!
  
 
  I'll 2nd that.
 
  For the following reasons, I think it might be nice to move existing
  examples out of core into their own git repo(s).
 
   * Examples would be based on released version of Accumulo
   * Examples could easily be built w/o building all of Accumulo
   * As Sean said, this would keep us honest
   * The examples poms would serve as examples more than they do when part
 of
  Accumulo build
   * Less likely to use non public APIs in examples
 
 
  
  
  
   On Wed, Nov 12, 2014 at 2:54 PM, Josh Elser josh.el...@gmail.com
  wrote:
  
My worry with a contrib module is that, historically, code which goes
moves to a contrib is just one step away from the grave. I think
  there's
precedence for keeping them in core (as Christopher had mentioned,
 next
   to
examples/simple) which would benefit people externally (more how do
 I
  do
X examples) and internally (keep devs honest about how our APIs are
implemented).
   
Bringing the examples into the core also encourages us to grow the
community which has been stagnant with respect to new committers for
   about
9 months now.
   
   
Corey Nolet wrote:
   
+1 for adding the examples to contrib.
   
I was, myself, reading over this email wondering how a set of 11
   separate
examples on the use of Accumulo would fit into the core codebase-
especially as more are contributed over tinme. I like the idea of
  giving
community members an outlet for contributing examples that they've
  built
so
that we can continue to foster that without having to fit them in
 the
   core
codebase. It just seems more maintainable.
   
   
On Wed, Nov 12, 2014 at 2:19 PM, Josh Elserjosh.el...@gmail.com
   wrote:
   
 I'll take that as you disagree with my consideration of
  substantial.
Thanks.
   
   
Mike Drob wrote:
   
 The proposed contribution is a collection of 11 examples. It's
  clearly
non-trivial, which is probably enough to be considered
 substantial
   
On Wed, Nov 12, 2014 at 12:58 PM, Josh Elserjosh.el...@gmail.com
 
wrote:
   
   
 Sean Busbey wrote:
   
  On Wed, Nov 12, 2014 at 12:31 PM, Josh Elser
  josh.el...@gmail.com
   
wrote:
   
   Personally, I didn't really think that this contribution was
 in
   the
   
 spirit
of what the new codebase adoption guidelines were meant to
 cover.
   
Some extra examples which leverage what Accumulo already does
  seems
more
like improvements for new Accumulo users than anything else.
   
   
   It's content developed out side of the project list. That's
  all
   it
   
 takes to
require the trip through the Incubator checks as far as the ASF
guidelines
are concerned.
   
   
   
   From http://incubator.apache.org/ip-clearance/index.html
   

  From time to time, an external codebase is brought into the ASF
   that
is
not a separate incubating project but still represents a
  substantial
contribution that was not developed within the ASF's source
 control
system
and on our public mailing lists.

   
Not to look a gift-horse in the mouth (it is great work), but I
  don't
see
these examples as substantial. I haven't found guidelines yet
  that
better
clarify the definition of substantial.
   
   
   
   
  
 

Re: Contribute Examples/Exercises

[Corey Nolet]

+1 for adding the examples to contrib.

I was, myself, reading over this email wondering how a set of 11 separate
examples on the use of Accumulo would fit into the core codebase-
especially as more are contributed over tinme. I like the idea of giving
community members an outlet for contributing examples that they've built so
that we can continue to foster that without having to fit them in the core
codebase. It just seems more maintainable.


On Wed, Nov 12, 2014 at 2:19 PM, Josh Elser josh.el...@gmail.com wrote:

 I'll take that as you disagree with my consideration of substantial.
 Thanks.


 Mike Drob wrote:

 The proposed contribution is a collection of 11 examples. It's clearly
 non-trivial, which is probably enough to be considered substantial

 On Wed, Nov 12, 2014 at 12:58 PM, Josh Elserjosh.el...@gmail.com
 wrote:


 Sean Busbey wrote:

  On Wed, Nov 12, 2014 at 12:31 PM, Josh Elserjosh.el...@gmail.com
 wrote:

   Personally, I didn't really think that this contribution was in the

 spirit
 of what the new codebase adoption guidelines were meant to cover.

 Some extra examples which leverage what Accumulo already does seems
 more
 like improvements for new Accumulo users than anything else.


   It's content developed out side of the project list. That's all it

 takes to
 require the trip through the Incubator checks as far as the ASF
 guidelines
 are concerned.



   From http://incubator.apache.org/ip-clearance/index.html

 
  From time to time, an external codebase is brought into the ASF that is
 not a separate incubating project but still represents a substantial
 contribution that was not developed within the ASF's source control
 system
 and on our public mailing lists.
 

 Not to look a gift-horse in the mouth (it is great work), but I don't see
 these examples as substantial. I haven't found guidelines yet that
 better
 clarify the definition of substantial.

Re: Contribute Examples/Exercises

[Corey Nolet]

Josh,

 My worry with a contrib module is that, historically, code which goes
moves to a contrib is just one step away from the grave.

You do have a good point. My hope was that this could be the beginning of
our changing history so that we could begin to encourage the community to
contribute their own source directly and give them an outlet for doing so.
I understand that's also the intent of hosting open source repos under ASF
to begin with- so I'm partial to either outcome.

 I think there's precedence for keeping them in core (as Christopher had
mentioned, next to examples/simple) which would benefit people externally
(more how do I do X examples) and internally (keep devs honest about how
our APIs are implemented).

I would think that would just require keeping the repos up to date as
versions change so they wouldn't get out of date and possibly releasing
them w/ our other releases.


Wherever they end up living, thank you Adam for the contributions!



On Wed, Nov 12, 2014 at 2:54 PM, Josh Elser josh.el...@gmail.com wrote:

 My worry with a contrib module is that, historically, code which goes
 moves to a contrib is just one step away from the grave. I think there's
 precedence for keeping them in core (as Christopher had mentioned, next to
 examples/simple) which would benefit people externally (more how do I do
 X examples) and internally (keep devs honest about how our APIs are
 implemented).

 Bringing the examples into the core also encourages us to grow the
 community which has been stagnant with respect to new committers for about
 9 months now.


 Corey Nolet wrote:

 +1 for adding the examples to contrib.

 I was, myself, reading over this email wondering how a set of 11 separate
 examples on the use of Accumulo would fit into the core codebase-
 especially as more are contributed over tinme. I like the idea of giving
 community members an outlet for contributing examples that they've built
 so
 that we can continue to foster that without having to fit them in the core
 codebase. It just seems more maintainable.


 On Wed, Nov 12, 2014 at 2:19 PM, Josh Elserjosh.el...@gmail.com  wrote:

  I'll take that as you disagree with my consideration of substantial.
 Thanks.


 Mike Drob wrote:

  The proposed contribution is a collection of 11 examples. It's clearly
 non-trivial, which is probably enough to be considered substantial

 On Wed, Nov 12, 2014 at 12:58 PM, Josh Elserjosh.el...@gmail.com
 wrote:


  Sean Busbey wrote:

   On Wed, Nov 12, 2014 at 12:31 PM, Josh Elserjosh.el...@gmail.com

 wrote:

Personally, I didn't really think that this contribution was in the

  spirit
 of what the new codebase adoption guidelines were meant to cover.

 Some extra examples which leverage what Accumulo already does seems
 more
 like improvements for new Accumulo users than anything else.


It's content developed out side of the project list. That's all it

  takes to
 require the trip through the Incubator checks as far as the ASF
 guidelines
 are concerned.



From http://incubator.apache.org/ip-clearance/index.html

 
   From time to time, an external codebase is brought into the ASF that
 is
 not a separate incubating project but still represents a substantial
 contribution that was not developed within the ASF's source control
 system
 and on our public mailing lists.
 

 Not to look a gift-horse in the mouth (it is great work), but I don't
 see
 these examples as substantial. I haven't found guidelines yet that
 better
 clarify the definition of substantial.

Re: C++ accumulo client -- native clients for Python, Go, Ruby etc

[Corey Nolet]

I'm all for this- though I'm curious to know the thoughts about maintenance
and the design. Are we going to use thrift to tie the C++ client calls into
the server-side components? Is that going to be maintained through a
separate effort or is the plan to  have the Accumulo community officially
support it?

On Mon, Oct 6, 2014 at 2:34 PM, Josh Elser josh.el...@gmail.com wrote:

 It'd be really cool to see a C++ client -- fully implemented or not. The
 increased performance via other languages like you said would be really
 nice, but I'd also be curious to see how the server characteristics change
 when the client might be sending data at a much faster rate.

 My C++ is super rusty these days, but I'd be happy to help out any devs
 who can spearhead the effort :)


 John R. Frank wrote:

 Accumulo Developers,

 We're trying to boost throughput of non-Java tools with Accumulo.  It
 seems that the lowest hanging fruit is to stop using the thrift proxy. Per
 discussion about Python and thrift proxy in the users list [1], I'm
 wondering if anyone is interested in helping with a native C++ client?
 There is a start on one here [2]. We could offer a bounty or maybe make a
 consulting project depending who is interested in it.

 We also looked at trying to run a separate thrift proxy for every worker
 thread or process.  With many cores on a box, eg 32, it just doesn't seem
 practical to run that many proxies, even if they all run on a single JVM.
 We'd be glad to hear ideas on that front too.

 A potentially big benefit of making a proper C++ accumulo client is that
 it is straightforward to expose native interfaces in Python (via pyObject),
 Go [3], Ruby [4], and other languages.

 Thanks for any advice, pointers, interest.

 John


 1-- http://www.mail-archive.com/user@accumulo.apache.org/msg03999.html

 2--
 https://github.com/phrocker/apeirogon

 3-- http://golang.org/cmd/cgo/

 4-- https://www.amberbit.com/blog/2014/6/12/calling-c-cpp-from-ruby/


 Sent from +1-617-899-2066

[ANNOUNCE] Apache 1.6.1 Released

[Corey Nolet]

The Apache Accumulo project is happy to announce its 1.6.1 release.

Version 1.6.1 is the most recent bug-fix release in its 1.6.x release line.
This version includes numerous bug fixes and performance improvements over
previous versions. Existing users of 1.6.x are encouraged to upgrade to
this version. Users new to Accumulo are encouraged to start with this
version as well.

The Apache Accumulo sorted, distributed key/value store is a robust,
scalable, high performance data storage system that features cell-based
access control and customizable server-side processing.  It is based on
Google's BigTable design and is built on top of Apache Hadoop, Apache
Zookeeper, and Apache Thrift.

The release is available at http://accumulo.apache.org/downloads/ and
release notes at http://accumulo.apache.org/release_notes/1.6.1.html.


Thanks.

- The Apache Accumulo Team

Re: Accumulo Powered By Logo

[Corey Nolet]

I think a logo that's more friendly to place in a circle would be useful.
The Accumulo logo is very squared off.

On Thu, Oct 2, 2014 at 3:39 PM, Mike Drob mad...@cloudera.com wrote:

 Yea, as an outside observer, I would have no idea what Apache A is, nor
 any idea how to get more information. Maybe we just need a different logo,
 altogether, given the context of putting it in the PBA circle.

 On Thu, Oct 2, 2014 at 2:36 PM, Keith Turner ke...@deenlo.com wrote:

  I was a looking at the new Accumulo powered logo [1] and thought that
 just
  an A[2] may be better.  Any other thoughts on how to improve this?
 
  Someone mentioned that just the A[2] isn't as informative in the case
 where
  someone is completely unfamiliar w/ Accumulo.
 
  [1]: http://apache.org/foundation/press/kit/poweredBy/pb-accumulo.jpg
  [2]: http://people.apache.org/~kturner/pb-accumulo.png
 

Re: [VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

I'm seeing the behavior under Max OS X and Fedora 19 and they have been
consistently failing for me. I'm thinking ACCUMULO-3073. Since others are
able to get it to pass, I did not think it should fail the vote solely on
that but I do think it needs attention, quickly.

On Thu, Sep 25, 2014 at 10:43 AM, Bill Havanki bhava...@clouderagovt.com
wrote:

 I haven't had an opportunity to try it again since my +1, but prior to that
 it has been consistently failing.

 - I tried extending the timeout on the test, but it would still time out.
 - I see the behavior on Mac OS X and under CentOS. (I wonder if it's a JVM
 thing?)

 On Wed, Sep 24, 2014 at 9:06 PM, Corey Nolet cjno...@gmail.com wrote:

  Vote passes with 4 +1's and no -1's.
 
  Bill, were you able to get the IT to run yet? I'm still having timeouts
 on
  my end as well.
 
 
  On Wed, Sep 24, 2014 at 1:41 PM, Josh Elser josh.el...@gmail.com
 wrote:
 
   The crux of it is that both of the errors in the CRC where single bit
   variants.
  
   y instead of 9 and p instead of 0
  
   Both of these cases are a '1' in the most significant bit of the byte
   instead of a '0'. We recognized these because y and p are outside of
 the
   hex range. Fixing both of these fixes the CRC error (manually
 verified).
  
   That's all we know right now. I'm currently running memtest86. I do not
   have ECC ram, so it *is* theoretically possible that was the cause.
 After
   running memtest for a day or so (or until I need my desktop functional
   again), I'll go back and see if I can reproduce this again.
  
  
   Mike Drob wrote:
  
   Any chance the IRC chats can make it only the ML for posterity?
  
   Mike
  
   On Wed, Sep 24, 2014 at 12:04 PM, Keith Turnerke...@deenlo.com
  wrote:
  
On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks
 rwe...@newbrightidea.com
   wrote:
  
Interesting that y (0x79) and 9 (0x39) are one bit away from
  each
   other. I blame cosmic rays!
  
It is interesting, and thats only half of the story.  Its been
   interesting
   chatting w/ Josh about this on irc and hearing about his findings.
  
  
On Wed, Sep 24, 2014 at 9:05 AM, Josh Elserjosh.el...@gmail.com
  
   wrote:
  
   The offending keys are:
  
   389a85668b6ebf8e 2ff6:4a78 [] 1411499115242
  
   3a10885b-d481-4d00-be00-0477e231ey65:8576b169:
   0cd98965c9ccc1d0:ba15529e
  
The careful eye will notice that the UUID in the first component
  of
   the
   value has a different suffix than the next corrupt key/value (ends
  with
   ey65 instead of e965). Fixing this in the Value and re-running
  the
  
   CRC
  
   makes it pass.
  
  
 and
  
   7e56b58a0c7df128 5fa0:6249 [] 1411499311578
  
   3a10885b-d481-4d00-be00-0477e231e965:p000872d60eb:
   499fa72752d82a7c:5c5f19e8
  
  
  
  
 



 --
 // Bill Havanki
 // Solutions Architect, Cloudera Govt Solutions
 // 443.686.9283

Re: [accumulo] your /dist/ artifacts - 1 BAD signature

[Corey Nolet]

I see what happened. I was expecting the mvn:release plugin to push the
prepare for next development iteration which it did not. I just pushed it
up and created the tag. I'll work on the release notes in a bit.

On Thu, Sep 25, 2014 at 3:33 PM, Christopher ctubb...@apache.org wrote:

 [note: thread moved to dev@]

 Okay, I just confirmed that the current files in dist are the same ones in
 Maven Central are the same ones that we voted on. So, that issue is
 resolved. I double checked and saw that the gpg-signed tag hasn't been
 created for 1.6.1 (git tag -s 1.6.1 origin/1.6.1-rc1). I guess technically
 anybody could do this, and merge it (along with the version bump to
 1.6.2-SNAPSHOT commit) to 1.6.2-SNAPSHOT branch (and forward, with -sours),
 if Corey doesn't have time/gets busy.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Sep 25, 2014 at 2:21 PM, Corey Nolet cjno...@gmail.com wrote:

  There's still a few things I need to do before announcing the release to
  the user list. Merging the rc into the next version branch was one of
 them
  and creating the official release tag was another. I'll do these tonight
 as
  well as writing up the release notes for the site.
 
 
  On Thu, Sep 25, 2014 at 1:59 PM, Christopher ctubb...@apache.org
 wrote:
 
   Also, we can move this list to dev@. There's no reason for it to be
   private@
   .
  
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
   On Thu, Sep 25, 2014 at 1:59 PM, Christopher ctubb...@apache.org
  wrote:
  
There's one more problem that Keith and I found... it doesn't look
 like
the rc1 branch got merged to 1.6.2-SNAPSHOT. I don't know if some
 other
branch got accidentally merged instead.
   
   
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
   
On Thu, Sep 25, 2014 at 1:40 PM, Josh Elser josh.el...@gmail.com
   wrote:
   
Things look good to me now. I checked the artifacts on dist/ against
   what
I have from evaluating the RC and they appear to match.
   
Anything else we need to do here?
   
   
Christopher wrote:
   
I was able to confirm the signature is bad. When I checked the RC,
  the
signature was good, so I'm guessing the wrong one just got
 uploaded.
  I
don't have a copy of the RC that I had previously downloaded, but I
  was
able to grab a copy of what was deployed to Maven central and fix
 the
dist
sigs/checksums from that.
   
Now, it's possible that the wrong artifacts were uploaded to Maven
central
(perhaps the wrong staging repo was promoted?) I can't know that
 for
sure,
until I can get to work and check my last download from the RC vote
  and
compare with what's in Maven central now. If that is the case, then
  we
need
to determine precisely what is different from this upload and what
  was
voted on and see if we need to immediately re-release as 1.6.2 to
 fix
   the
problems.
   
   
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
   
On Thu, Sep 25, 2014 at 3:12 AM, Henk Penninghe...@apache.org
   wrote:
   
 Hi PMC accumulo,
   
   I watch 'www.apache.org/dist/', and I noticed that :
   
   -- you have 1 BAD pgp signature
   
accumulo/1.6.1/accumulo-1.6.1-src.tar.gz.asc
   
   Please fix this problem soon ; for details, see
   
   
   http://people.apache.org/~henkp/checker/sig.html#project-accumulo
 http://people.apache.org/~henkp/checker/md5.html
   
   For information on how to fix problems, see the faq :
   
 http://people.apache.org/~henkp/checker/faq.html
   
   Thanks a lot, regards,
   
   Henk Penning -- apache.org infrastructure
   
   PS. The contents of this message is generated,
   but the mail itself is sent by hand.
   PS. Please cc me on all relevant emails.
   
-   _
Henk P. Penning, ICT-beta  R Uithof WISK-412  _/ _
Faculty of Science, Utrecht University T +31 30 253 4106 / _/
Budapestlaan 6, 3584CD Utrecht, NL F +31 30 253 4553 _/ _/
http://people.cs.uu.nl/henkp/  M penn...@uu.nl _/
   
   
   
   
  
 

Re: [VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

Christopher, are you referring to Keith's last comment or Bill Slacum's?

On Thu, Sep 25, 2014 at 9:13 PM, Christopher ctubb...@apache.org wrote:

 That seems like a reason to vote -1 (and perhaps to encourage others to do
 so also). I'm not sure this can be helped so long as people have different
 criteria for their vote, though. If we can fix those issues, I'm ready to
 vote on a 1.6.2 :)


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Sep 25, 2014 at 2:42 PM, William Slacum 
 wilhelm.von.cl...@accumulo.net wrote:

  I'm a little concerned we had two +1's that mention failures. The one
 time
  when we're supposed to have a clean run through, we have 50% of the
  participators noticing failure. It doesn't instill much confidence in me.
 
  On Thu, Sep 25, 2014 at 2:18 PM, Josh Elser josh.el...@gmail.com
 wrote:
 
   Please make a ticket for it and supply the MAC directories for the test
   and the failsafe output.
  
   It doesn't fail for me. It's possible that there is some edge case that
   you and Bill are hitting that I'm not.
  
  
   Corey Nolet wrote:
  
   I'm seeing the behavior under Max OS X and Fedora 19 and they have
 been
   consistently failing for me. I'm thinking ACCUMULO-3073. Since others
  are
   able to get it to pass, I did not think it should fail the vote solely
  on
   that but I do think it needs attention, quickly.
  
   On Thu, Sep 25, 2014 at 10:43 AM, Bill Havanki
  bhava...@clouderagovt.com
   wrote:
  
I haven't had an opportunity to try it again since my +1, but prior
 to
   that
   it has been consistently failing.
  
   - I tried extending the timeout on the test, but it would still time
  out.
   - I see the behavior on Mac OS X and under CentOS. (I wonder if it's
 a
   JVM
   thing?)
  
   On Wed, Sep 24, 2014 at 9:06 PM, Corey Noletcjno...@gmail.com
  wrote:
  
Vote passes with 4 +1's and no -1's.
  
   Bill, were you able to get the IT to run yet? I'm still having
  timeouts
  
   on
  
   my end as well.
  
  
   On Wed, Sep 24, 2014 at 1:41 PM, Josh Elserjosh.el...@gmail.com
  
   wrote:
  
   The crux of it is that both of the errors in the CRC where single
 bit
   variants.
  
   y instead of 9 and p instead of 0
  
   Both of these cases are a '1' in the most significant bit of the
 byte
   instead of a '0'. We recognized these because y and p are outside
 of
  
   the
  
   hex range. Fixing both of these fixes the CRC error (manually
  
   verified).
  
   That's all we know right now. I'm currently running memtest86. I do
  not
   have ECC ram, so it *is* theoretically possible that was the cause.
  
   After
  
   running memtest for a day or so (or until I need my desktop
 functional
   again), I'll go back and see if I can reproduce this again.
  
  
   Mike Drob wrote:
  
Any chance the IRC chats can make it only the ML for posterity?
  
   Mike
  
   On Wed, Sep 24, 2014 at 12:04 PM, Keith Turnerke...@deenlo.com
  
   wrote:
  
 On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks
  
   rwe...@newbrightidea.com
  
   wrote:
  
 Interesting that y (0x79) and 9 (0x39) are one bit away
  from
  
   each
  
   other. I blame cosmic rays!
  
 It is interesting, and thats only half of the story.  Its been
  
   interesting
   chatting w/ Josh about this on irc and hearing about his
 findings.
  
  
 On Wed, Sep 24, 2014 at 9:05 AM, Josh Elser
 josh.el...@gmail.com
  
   wrote:
  
The offending keys are:
  
   389a85668b6ebf8e 2ff6:4a78 [] 1411499115242
  
   3a10885b-d481-4d00-be00-0477e231ey65:8576b169:
   0cd98965c9ccc1d0:ba15529e
  
 The careful eye will notice that the UUID in the first
   component
  
   of
  
   the
   value has a different suffix than the next corrupt key/value
  (ends
  
   with
  
   ey65 instead of e965). Fixing this in the Value and re-running
  
   the
  
   CRC
  
makes it pass.
  
  
  and
  
7e56b58a0c7df128 5fa0:6249 [] 1411499311578
  
   3a10885b-d481-4d00-be00-0477e231e965:p000872d60eb:
   499fa72752d82a7c:5c5f19e8
  
  
  
  
  
   --
   // Bill Havanki
   // Solutions Architect, Cloudera Govt Solutions
   // 443.686.9283
  
  
  
 

Re: [VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

Bill,

I've been having that same IT issue and said the same thing It's not
happening to others. I lifted the timeout completely and it never finished.


On Wed, Sep 24, 2014 at 1:13 PM, Mike Drob mad...@cloudera.com wrote:

 Any chance the IRC chats can make it only the ML for posterity?

 Mike

 On Wed, Sep 24, 2014 at 12:04 PM, Keith Turner ke...@deenlo.com wrote:

  On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks rwe...@newbrightidea.com
  wrote:
 
   Interesting that y (0x79) and 9 (0x39) are one bit away from each
   other. I blame cosmic rays!
  
 
  It is interesting, and thats only half of the story.  Its been
 interesting
  chatting w/ Josh about this on irc and hearing about his findings.
 
 
  
   On Wed, Sep 24, 2014 at 9:05 AM, Josh Elser josh.el...@gmail.com
  wrote:
  
   
The offending keys are:
   
389a85668b6ebf8e 2ff6:4a78 [] 1411499115242
   
3a10885b-d481-4d00-be00-0477e231ey65:8576b169:
0cd98965c9ccc1d0:ba15529e
   
   
The careful eye will notice that the UUID in the first component of
 the
value has a different suffix than the next corrupt key/value (ends
 with
ey65 instead of e965). Fixing this in the Value and re-running
 the
   CRC
makes it pass.
   
   
 and
   
7e56b58a0c7df128 5fa0:6249 [] 1411499311578
   
3a10885b-d481-4d00-be00-0477e231e965:p000872d60eb:
499fa72752d82a7c:5c5f19e8
   
   
  
 

Re: [DISCUSS] Thinking about branch names

[Corey Nolet]

+1

Using separate branches in this manner just adds complexity. I was
wondering myself why we needed to create separate branches when all we're
doing is tagging/deleting the already released ones. The only difference
between where one leaves off and another begins  is the name of the branch.


On Tue, Sep 23, 2014 at 9:04 AM, Christopher ctubb...@apache.org wrote:

 +1 to static dev branch names per release series. (this would also fix the
 Jenkins spam when the builds break due to branch name changes)

 However, I kind of prefer 1.5.x or 1.5-dev, or similar, over simply 1.5,
 which looks so much like a release version that I wouldn't want it to
 generate any confusion.

 Also, for reference, here's a few git commands that might help some people
 avoid the situation that happened:
 git remote update
 git remote prune $(git remote)
 git config --global push.default current # git  1.8
 git config --global push.default simple # git = 1.8

 The situation seems to primarily have occurred because of some pushes that
 succeeded because the local clone was not aware that the remote branches
 had disappeared. Pruning will clean those up, so that you'll get an error
 if you try to push. Simple/current push strategy will ensure you don't push
 all matching branches by default. Josh's proposed solution makes it less
 likely the branches will disappear/change on a remote, but these are still
 useful git commands to be aware of, and are related enough to this
 situation, I thought I'd share.



 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Mon, Sep 22, 2014 at 11:18 PM, Josh Elser josh.el...@gmail.com wrote:

  After working on 1.5.2 and today's branch snafu, I think I've come to the
  conclusion that our branch naming is more pain than it's worth (I
 believe I
  was the one who primarily argued for branch names as they are current
  implemented, so take that as you want).
 
  * Trying to making a new branch for the next version as a release is
  happening forces you to fight with Maven. Maven expects that your next
 is
  going to be on the same branch and the way it makes commits and bumps
  versions for you encourages this. Using a new branch for next is more
  manual work for the release manager.
 
  * The time after we make a release, there's a bit of confusion (I do it
  too, just not publicly... yet) about what branch do I put this fix for
  _version_ in?. It's not uncommon to put it in the old branch instead
 of
  the new one. The problem arises when the old branch has already been
  deleted. If a developer has an old version of that branch, there's
 nothing
  to tell them hey, your copy of this branch is behind the remote's copy
 of
  this branch. I'm not accepting your push! Having a single branch for a
  release line removes this hassle.
 
  Pictorially, I'm thinking we would change from the active branches
  {1.5.3-SNAPSHOT, 1.6.1-SNAPSHOT, 1.6.2-SNAPSHOT, master} to {1.5, 1.6,
  master}. (where a git tag would exist for the 1.6.1 RCs).
 
  IIRC, the big argument for per-release branches was of encouraging
  frequent, targeted branches (I know the changes for this version go in
 this
  branch). I think most of this can be mitigated by keeping up with
 frequent
  releases and coordination with the individual cutting the release.
 
  In short, I'm of the opinion that I think we should drop the
 .z-SNAPSHOT
  suffix from branch names (e.g. 1.5.3-SNAPSHOT) and move to a shorter
 x.y
  (e.g. 1.5) that exists for the lifetime of that version. I think we could
  also use this approach if/when we change our versioning to start using
 the
  x component of x.y.z.
 
  Thoughts?
 
  - Josh
 

Re: [VOTE] Apache Accumulo 1.5.2 RC1

[Corey Nolet]

If we are concerned with confusion about adoption of new versions, we
should make a point to articulate the purpose very clearly in each of the
announcements. I was in the combined camp an hour ago and now I'm also
thinking we should keep them separate.


On Fri, Sep 19, 2014 at 1:16 AM, Josh Elser josh.el...@gmail.com wrote:

 No we did not bundle any release announcements prior. I also have to agree
 with Bill -- I don't really see how there would be confusion with a
 properly worded announcement.

 Happy to work with anyone who has concerns in this regard to come up with
 something that is agreeable. I do think they should be separate.


 On 9/19/14, 1:02 AM, Mike Drob wrote:

 Did we bundle 1.5.1/1.6.0? If not, they were fairly close together, I
 think. Historically, we have not done a great job of distinguishing our
 release lines, so that has led to confusion. Maybe I'm on the path to
 talking myself out of a combined announcement here.

 On Thu, Sep 18, 2014 at 9:57 PM, William Slacum 
 wilhelm.von.cl...@accumulo.net wrote:

  Not to be a total jerk, but what's unclear about 1.5  1.6? Lots of
 projects have multiple release lines and it's not an issue.

 On Fri, Sep 19, 2014 at 12:18 AM, Mike Drob mad...@cloudera.com wrote:

  +1 to combining. I've already had questions about upgrading to this

 latest

 release from somebody currently on the 1.6 line. Our release narrative

 is

 not clear and we should not muddle the waters.

 On Thu, Sep 18, 2014 at 7:27 PM, Christopher ctubb...@apache.org

 wrote:


  Should we wait to do a release announcement until 1.6.1, so we can

 batch

 the two?

 My main concern here is that I don't want to encourage new 1.5.x

 adoption

 when we have 1.6.x, and having two announcements could be confusing to

 new

 users who aren't sure which version to start using. We could issue an
 announcement that primarily mentions 1.6.1, and also mentions 1.5.2

 second.

 That way, people will see 1.6.x as the stable/focus release, but will

 still

 inform 1.5.x users of updates.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Sep 18, 2014 at 10:20 PM, Josh Elser josh.el...@gmail.com

 wrote:


  Vote passes with 3 +1's and nothing else. Huge thank you to those who

 made

 the time to participate.

 I'll finish up the rest of the release work tonight.

 On 9/15/14, 12:24 PM, Josh Elser wrote:

  Devs,

 Please consider the following candidate for Apache Accumulo 1.5.2

 Tag: 1.5.2rc1
 SHA1: 039a2c28bdd474805f34ee33f138b009edda6c4c
 Staging Repository:
 https://repository.apache.org/content/repositories/
 orgapacheaccumulo-1014/

 Source tarball:
 http://repository.apache.org/content/repositories/
 orgapacheaccumulo-1014/org/apache/accumulo/accumulo/1.5.
 2/accumulo-1.5.2-src.tar.gz

 Binary tarball:
 http://repository.apache.org/content/repositories/
 orgapacheaccumulo-1014/org/apache/accumulo/accumulo/1.5.
 2/accumulo-1.5.2-bin.tar.gz

 (Append .sha1, .md5 or .asc to download the signature/hash

 for a

 given artifact.)

 Signing keys available at:

 https://www.apache.org/dist/accumulo/KEYS


 Over 1.5.1, we have 109 issues resolved
 https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
 blob;f=CHANGES;h=c2892d6e9b1c6c9b96b2a58fc901a76363ece8b0;hb=
 039a2c28bdd474805f34ee33f138b009edda6c4c


 Testing: all unit and functional tests are passing and ingested 1B
 entries using CI w/ agitation over rc0.

 Vote will be open until Friday, August 19th 12:00AM UTC (8/18 8:00PM

 ET,

 8/18 5:00PM PT)

 - Josh

Re: Time to release 1.6.1?

[Corey Nolet]

I'm on it. I'll get a more formal vote going after I dig through the jira a
bit and note what's changed.

On Thu, Sep 11, 2014 at 11:06 AM, Christopher ctubb...@apache.org wrote:

 Also, we can always have a 1.6.2 if there's outstanding bugfixes to release
 later.


 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii

 On Thu, Sep 11, 2014 at 10:36 AM, Eric Newton eric.new...@gmail.com
 wrote:

  +1 for 1.6.1.
 
  There are people testing a recent 1.6 branch at scale (100s of nodes),
 with
  the intent of pushing it to production.
 
  I would rather have a released version in production.
 
  Thanks for volunteering.  Feel free to contact me if you need a hand with
  anything.
 
  -Eric
 
 
  On Wed, Sep 10, 2014 at 1:49 PM, Josh Elser josh.el...@gmail.com
 wrote:
 
   Sure that's fine, Corey. Happy to help coordinate things with you.
   *Hopefully* it's not too painful :)
  
  
   On 9/10/14, 10:43 AM, Corey Nolet wrote:
  
   I had posted this to the mailing list originally after a discussion
 with
   Christopher at the Accumulo Summit hack-a-thon and because I wanted to
  get
   into the release process to help out.
  
   Josh, I still wouldn't mind getting together 1.6.1 if that's okay with
   you.
   If nothing else, it would get someone else following the procedures
 and
   able to do the release.
  
   On Wed, Sep 10, 2014 at 1:22 PM, Josh Elser josh.el...@gmail.com
  wrote:
  
That's exactly my plan, Christopher. Keith has been the man working
 on
  a
   fix for ACCUMULO-1628 which is what I've been spinning on to get
 1.5.2
   out
   the door. I want to spend a little time today looking at his patch to
   understand the fix and run some tests myself. Hopefully John can
 retest
   the
   patch as well since he had an environment that could reproduce the
 bug.
  
   Right after we get 1.5.2, I'm happy to work on 1.6.1 as well.
  
   - Josh
  
  
   On 9/10/14, 10:04 AM, Christopher wrote:
  
Because of ACCUMULO-2988 (upgrade path from 1.4.x -- 1.6.y, y =
 1),
   I'm
   hoping we can revisit this soon. Maybe get 1.5.2 out the door,
  followed
   by
   1.6.1 right away.
  
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
   On Fri, Jun 20, 2014 at 10:30 AM, Keith Turner ke...@deenlo.com
   wrote:
  
 On Thu, Jun 19, 2014 at 11:46 AM, Josh Elser 
 josh.el...@gmail.com
  
   wrote:
  
 I was thinking the same thing, but I also haven't made any
 strides
  
  
towards
  
getting 1.5.2 closer to happening (as I said I'd try to do).
  
   I still lack physical resources to do the week-long testing as
 our
   guidelines currently force us to do. I still think this testing is
   excessive if we're actually releasing bug-fixes, but it does
  
differentiate
  
us from other communities.
  
  
I want to run some CI test because of the changes I made w/
 walog.
   I can
   run the test, but I would like to do that as late as possible.
  Just
   let
   me know when you are thinking of cutting a release.
  
   Also, I would like to get 2827 in for the release.
  
  
  
I'm really not sure how to approach this which is really why I've
  been
   stalling on it.
  
  
   On 6/19/14, 7:18 AM, Mike Drob wrote:
  
 I'd like to see 1.5.2 released first, just in case there are
  issues
   we
  
   discover during that process that need to be addressed. Also, I
  think
   it
   would be useful to resolve the discussion surrounding upgrades[1]
   before
   releasing.
  
   [1]:
   http://mail-archives.apache.org/mod_mbox/accumulo-dev/
   201406.mbox/%3CCAGHyZ6LFuwH%3DqGF9JYpitOY9yYDG-
   sop9g6iq57VFPQRnzmyNQ%40mail.gmail.com%3E
  
  
   On Thu, Jun 19, 2014 at 8:09 AM, Corey Nolet cjno...@gmail.com
   wrote:
  
  I'd like to start getting a candidate together if there are no
  
objections.
  
   It looks like we have 65 resolved tickets with a fix version of
   1.6.1.
  
  
  
  
  
  
  
  
 

Re: Tablet server thrift issue

[Corey Nolet]

As an update,

I raised the tablet server memory and I have not seen this error thrown
since. I'd like to say raising the memory, alone, was the solution but it
appears that I also may be having some performance issues with the switches
connecting the racks together. I'll update more as I dive in further.


On Fri, Aug 22, 2014 at 11:41 PM, Corey Nolet cjno...@gmail.com wrote:

 Josh,

 Your advice is definitely useful- I also thought about catching the
 exception and retrying with a fresh batch writer but the fact that the
 batch writer failure doesn't go away without being re-instantiated is
 really only a nuisance. The TabletServerBatchWriter could be designed much
 better, I agree, but that is not the root of the problem.

 The Thrift exception that is causing the issue is what I'd like to get to
 the bottom of. It's throwing the following:

 *TApplicationException: applyUpdates failed: out of sequence response *

 I've never seen this exception before in regular use of the client API-
 but I also just updated to 1.6.0. Google isn't showing anything useful for
 how exactly this exception could come about other than using a bad
 threading model- and I don't see any drastic changes or other user
 complaints on the mailing list that would validate that line of thought.
 Quite frankly, I'm stumped. This could be a Thrift exception related to a
 Thrift bug or something bad on my system and have nothing to do with
 Accumulo.

 Chris Tubbs mentioned to me earlier that he recalled Keith and Eric had
 seen the exception before and may remember what it was/how they fixed it.


 On Fri, Aug 22, 2014 at 10:58 PM, Josh Elser josh.el...@gmail.com wrote:

 Don't mean to tell you that I don't think there might be a bug/otherwise,
 that's pretty much just the limit of what I know about the server-side
 sessions :)

 If you have concrete this worked in 1.4.4 and this happens instead
 with 1.6.0, that'd make a great ticket :D

 The BatchWriter failure case is pretty rough, actually. Eric has made
 some changes to help already (in 1.6.1, I think), but it needs an overhaul
 that I haven't been able to make time to fix properly, either. IIRC, the
 only guarantee you have is that all mutations added before the last flush()
 happened are durable on the server. Anything else is a guess. I don't know
 the specifics, but that should be enough to work with (and saving off
 mutations shouldn't be too costly since they're stored serialized).


 On 8/22/14, 5:44 PM, Corey Nolet wrote:

 Thanks Josh,

 I understand about the session ID completely but the problem I have is
 that
 the exact same client code worked, line for line, just fine in 1.4.4 and
 it's acting up in 1.6.0. I also seem to remember the BatchWriter
 automatically creating a new session when one expired without an
 exception
 causing it to fail on the client.

 I know we've made changes since 1.4.4 but I'd like to troubleshoot the
 actual issue of the BatchWriter failing due to the thrift exception
 rather
 than just catching the exception and trying mutations again. The other
 issue is that I've already submitted a bunch of mutations to the batch
 writer from different threads. Does that mean I need to be storing them
 off
 twice? (once in the BatchWriter's cache and once in my own)

 The BatchWriter in my ingester is constantly sending data and the tablet
 servers have been given more than enough memory to be able to keep up.
 There's no swap being used and the network isn't experiencing any errors.


 On Fri, Aug 22, 2014 at 4:54 PM, Josh Elser josh.el...@gmail.com
 wrote:

  If you get an error from a BatchWriter, you pretty much have to throw
 away
 that instance of the BatchWriter and make a new one. See ACCUMULO-2990.
 If
 you want, you should be able to catch/recover from this without having
 to
 restart the ingester.

 If the session ID is invalid, my guess is that it hasn't been used
 recently and the tserver cleaned it up. The exception logic isn't the
 greatest (as it just is presented to you as a RTE).

 https://issues.apache.org/jira/browse/ACCUMULO-2990


 On 8/22/14, 4:35 PM, Corey Nolet wrote:

  Eric  Keith, Chris mentioned to me that you guys have seen this issue
 before. Any ideas from anyone else are much appreciated as well.

 I recently updated a project's dependencies to Accumulo 1.6.0 built
 with
 Hadoop 2.3.0. I've got CDH 5.0.2 deployed. The project has an ingest
 component which is running all the time with a batch writer using many
 threads to push mutations into Accumulo.

 The issue I'm having is a show stopper. At different intervals of time,
 sometimes an hour, sometimes 30 minutes, I'm getting
 MutationsRejectedExceptions (server errors) from the
 TabletServerBatchWriter. Once they start, I need to restart the
 ingester
 to
 get them to stop. They always come back within 30 minutes to an hour...
 rinse, repeat.

 The exception always happens on different tablet servers. It's a thrift
 error saying a message was received out

Re: Tablet server thrift issue

[Corey Nolet]

Thanks Josh,

I understand about the session ID completely but the problem I have is that
the exact same client code worked, line for line, just fine in 1.4.4 and
it's acting up in 1.6.0. I also seem to remember the BatchWriter
automatically creating a new session when one expired without an exception
causing it to fail on the client.

I know we've made changes since 1.4.4 but I'd like to troubleshoot the
actual issue of the BatchWriter failing due to the thrift exception rather
than just catching the exception and trying mutations again. The other
issue is that I've already submitted a bunch of mutations to the batch
writer from different threads. Does that mean I need to be storing them off
twice? (once in the BatchWriter's cache and once in my own)

The BatchWriter in my ingester is constantly sending data and the tablet
servers have been given more than enough memory to be able to keep up.
There's no swap being used and the network isn't experiencing any errors.


On Fri, Aug 22, 2014 at 4:54 PM, Josh Elser josh.el...@gmail.com wrote:

 If you get an error from a BatchWriter, you pretty much have to throw away
 that instance of the BatchWriter and make a new one. See ACCUMULO-2990. If
 you want, you should be able to catch/recover from this without having to
 restart the ingester.

 If the session ID is invalid, my guess is that it hasn't been used
 recently and the tserver cleaned it up. The exception logic isn't the
 greatest (as it just is presented to you as a RTE).

 https://issues.apache.org/jira/browse/ACCUMULO-2990


 On 8/22/14, 4:35 PM, Corey Nolet wrote:

 Eric  Keith, Chris mentioned to me that you guys have seen this issue
 before. Any ideas from anyone else are much appreciated as well.

 I recently updated a project's dependencies to Accumulo 1.6.0 built with
 Hadoop 2.3.0. I've got CDH 5.0.2 deployed. The project has an ingest
 component which is running all the time with a batch writer using many
 threads to push mutations into Accumulo.

 The issue I'm having is a show stopper. At different intervals of time,
 sometimes an hour, sometimes 30 minutes, I'm getting
 MutationsRejectedExceptions (server errors) from the
 TabletServerBatchWriter. Once they start, I need to restart the ingester
 to
 get them to stop. They always come back within 30 minutes to an hour...
 rinse, repeat.

 The exception always happens on different tablet servers. It's a thrift
 error saying a message was received out of sequence. In the TabletServer
 logs, I see an Invalid session id exception which happens only once
 before the client-side batch writer starts spitting out the MREs.

 I'm running some heavyweight processing in Storm along side the tablet
 servers. I shut that processing off in hopes that maybe it was the culprit
 but that hasn't fixed the issue.

 I'm surprised I haven't seen any other posts on the topic.

 Thanks!

Re: Tablet server thrift issue

[Corey Nolet]

Josh,

Your advice is definitely useful- I also thought about catching the
exception and retrying with a fresh batch writer but the fact that the
batch writer failure doesn't go away without being re-instantiated is
really only a nuisance. The TabletServerBatchWriter could be designed much
better, I agree, but that is not the root of the problem.

The Thrift exception that is causing the issue is what I'd like to get to
the bottom of. It's throwing the following:

*TApplicationException: applyUpdates failed: out of sequence response *

I've never seen this exception before in regular use of the client API- but
I also just updated to 1.6.0. Google isn't showing anything useful for how
exactly this exception could come about other than using a bad threading
model- and I don't see any drastic changes or other user complaints on the
mailing list that would validate that line of thought. Quite frankly, I'm
stumped. This could be a Thrift exception related to a Thrift bug or
something bad on my system and have nothing to do with Accumulo.

Chris Tubbs mentioned to me earlier that he recalled Keith and Eric had
seen the exception before and may remember what it was/how they fixed it.


On Fri, Aug 22, 2014 at 10:58 PM, Josh Elser josh.el...@gmail.com wrote:

 Don't mean to tell you that I don't think there might be a bug/otherwise,
 that's pretty much just the limit of what I know about the server-side
 sessions :)

 If you have concrete this worked in 1.4.4 and this happens instead with
 1.6.0, that'd make a great ticket :D

 The BatchWriter failure case is pretty rough, actually. Eric has made some
 changes to help already (in 1.6.1, I think), but it needs an overhaul that
 I haven't been able to make time to fix properly, either. IIRC, the only
 guarantee you have is that all mutations added before the last flush()
 happened are durable on the server. Anything else is a guess. I don't know
 the specifics, but that should be enough to work with (and saving off
 mutations shouldn't be too costly since they're stored serialized).


 On 8/22/14, 5:44 PM, Corey Nolet wrote:

 Thanks Josh,

 I understand about the session ID completely but the problem I have is
 that
 the exact same client code worked, line for line, just fine in 1.4.4 and
 it's acting up in 1.6.0. I also seem to remember the BatchWriter
 automatically creating a new session when one expired without an exception
 causing it to fail on the client.

 I know we've made changes since 1.4.4 but I'd like to troubleshoot the
 actual issue of the BatchWriter failing due to the thrift exception rather
 than just catching the exception and trying mutations again. The other
 issue is that I've already submitted a bunch of mutations to the batch
 writer from different threads. Does that mean I need to be storing them
 off
 twice? (once in the BatchWriter's cache and once in my own)

 The BatchWriter in my ingester is constantly sending data and the tablet
 servers have been given more than enough memory to be able to keep up.
 There's no swap being used and the network isn't experiencing any errors.


 On Fri, Aug 22, 2014 at 4:54 PM, Josh Elser josh.el...@gmail.com wrote:

  If you get an error from a BatchWriter, you pretty much have to throw
 away
 that instance of the BatchWriter and make a new one. See ACCUMULO-2990.
 If
 you want, you should be able to catch/recover from this without having to
 restart the ingester.

 If the session ID is invalid, my guess is that it hasn't been used
 recently and the tserver cleaned it up. The exception logic isn't the
 greatest (as it just is presented to you as a RTE).

 https://issues.apache.org/jira/browse/ACCUMULO-2990


 On 8/22/14, 4:35 PM, Corey Nolet wrote:

  Eric  Keith, Chris mentioned to me that you guys have seen this issue
 before. Any ideas from anyone else are much appreciated as well.

 I recently updated a project's dependencies to Accumulo 1.6.0 built with
 Hadoop 2.3.0. I've got CDH 5.0.2 deployed. The project has an ingest
 component which is running all the time with a batch writer using many
 threads to push mutations into Accumulo.

 The issue I'm having is a show stopper. At different intervals of time,
 sometimes an hour, sometimes 30 minutes, I'm getting
 MutationsRejectedExceptions (server errors) from the
 TabletServerBatchWriter. Once they start, I need to restart the ingester
 to
 get them to stop. They always come back within 30 minutes to an hour...
 rinse, repeat.

 The exception always happens on different tablet servers. It's a thrift
 error saying a message was received out of sequence. In the TabletServer
 logs, I see an Invalid session id exception which happens only once
 before the client-side batch writer starts spitting out the MREs.

 I'm running some heavyweight processing in Storm along side the tablet
 servers. I shut that processing off in hopes that maybe it was the
 culprit
 but that hasn't fixed the issue.

 I'm surprised I haven't seen any other posts on the topic

Time to release 1.6.1?

[Corey Nolet]

I'd like to start getting a candidate together if there are no objections.

It looks like we have 65 resolved tickets with a fix version of 1.6.1.

Re: Is Data Locality Helpful? (or why run tserver and datanode on the same box?)

[Corey Nolet]

AFAIK, the locality may not be guaranteed right away unless the data for a
tablet was first ingested on the tablet server that is responsible for that
tablet, otherwise you'll need to wait for a major compaction to rewrite the
RFiles locally on the tablet server. I would assume if the tablet server is
not on the same node as the datanode, those files will probably be spread
across the cluster as if you were ingesting data from outside the cloud.

A recent discussion with Bill Slacum also brought to light a possible
problem of the HDFS balancer [1] re-balancing blocks after the fact which
could eventually pull blocks onto datanodes that are not local to the
tablets. I believe remedy for this was to turn off the balancer or not have
it run.

[1]
http://www.swiss-scalability.com/2013/08/hadoop-hdfs-balancer-explained.html




On Thu, Jun 19, 2014 at 10:07 AM, David Medinets david.medin...@gmail.com
wrote:

 At the Accumulo Summit and on a recent client site, there have been
 conversations about Data Locality and Accumulo.

 I ran an experiment to see that Accumulo can scan tables when the
 tserver process is run on a server without a datanode process. I
 followed these steps:

 1. Start three node cluster
 2. Load data
 3. Kill datanode on slave1
 4. Wait until Hadoop notices dead node.
 5. Kill tserver on slave2
 6. Wait until Accumulo notices dead node.
 7. Run the accumulo shell on master and slave1 to verify entries can be
 scanned.

 Accumulo handled this situation just fine. As I expected.

 How important (or not) is it to run tserver and datanode on the same
 server?
 Does the Data Locality implied by running them together exist?
 Can the benefit be quantified?

Re: Mini Accumulo Cluster Use Case: Development and Training

[Corey Nolet]

Wouldn't that take care of ACCUMULO-1378


On Fri, Jun 13, 2014 at 12:56 PM, Keith Turner ke...@deenlo.com wrote:

 On Thu, Jun 12, 2014 at 11:44 PM, Vicky Kak vicky@gmail.com wrote:

  Rather than having new development can't we add these features to the
  existing accumulo command line, I think these makes life easier and are
 not
  there in exsiting accumulo command line tool
 
  1. Persist the entire state of mini accumulo
 

 It would be nice if the default behavior of requiring an empty directory
 remained the same.  Some users may depend on this behaviour.  An option
 could be added to MiniAccumuloConfig that allows a user to enable directory
 reuse.


  4. Add a function to force re-initialization of the  MAC
 
 
  I just scanned the code but would like to run it too. Instantly I can say
  that the accumulo command line should be updated with these
  functionalities.
 
  Thanks,
  Vicky
 
 
 
 
 
  On Fri, Jun 13, 2014 at 3:40 AM, Andrew Wells awe...@clearedgeit.com
  wrote:
 
   I developed this tool for doing persistent Mini Accumulo Cluster for
   training, and others have said it would be useful for doing
 Development.
  
   It does the following,
  
   Allows for optional persistence of the tables.
  
   Allows for shell access to MAC
  
   Here is the the tool on github as it stands, it is pretty down and
 dirty:
  
   https://github.com/agwells0714/AccumuloDeveloperUtil
  
  
   I would like to start contributing code to OBSOLETE this project.
  
   I imagine the following would satisfy this requirement.
  
   1. Persist the entire state of mini accumulo
  
   2. allow shell access to MAC
  
   3. allow option to also start a monitor (for additional testing)
  
   4. Add a function to force re-initialization of the  MAC
  
  
   Thoughts? Suggestions?
  
   --
   *Andrew George Wells*
   *Software Engineer*
   *awe...@clearedgeit.com awe...@clearedgeit.com*
  
 

Re: Accumulo Summit Hackathon

[Corey Nolet]

+1 on the Ganglia integration.

Also, while we're on the topic of github projects for integrating with
Accumulo, I'd like to see Accuismus worked on as well.

https://github.com/keith-turner/Accismus


On Mon, Jun 9, 2014 at 7:11 PM, Alex Moundalexis al...@clouderagovt.com
wrote:

 I would love to see metrics2 from Hadoop Common implemented. Easier Ganglia
 integration without the use of JMX and conversion utilities.

 https://issues.apache.org/jira/browse/ACCUMULO-1817

 I knew I remembered an issue being open. :)


 On Sun, Jun 8, 2014 at 8:38 PM, Tamburello, Paul [USA] 
 tamburello_p...@bah.com wrote:

  Accumulo Development Team -
 
  As many of you already know, this week during the Accumulo Summit
  http://accumulosummit.com/, Booz Allen Hamilton is sponsoring a
  Hackathonhttp://accumulosummit.com/program/hackathon/ event following
  the conference, from 5PM til 11PM.  As part of the agenda, we are working
  to put together a list of existing JIRA tickets that folks can work on
  during the Hackathon, so we want to solicit input from the Accumulo
  contributors. So, if you have suggestions for tasks that people can work
  on, please respond directly to me and we will add them to our list.
 
  Thanks in advance, see you all on Thursday!
  Paul
 
  Paul Tamburello
  Senior Lead Engineer
  Strategic Innovation Group
  301-821-8861 / 919-260-6158
  tamburello_p...@bah.com
 

Re: [DISCUSS] Do we want contributors assigning to themselves?

[Corey Nolet]

+1 for restoring old behavior.Why wouldn't we allow contributors to help
themselves help the community?


On Thu, May 15, 2014 at 11:13 AM, John Vines vi...@apache.org wrote:

 Yes, restore the old behavior


 On Wed, May 14, 2014 at 4:38 PM, Sean Busbey bus...@cloudera.com wrote:

  We don't have a formal onboarding process for drawing in new
 contributors,
  but a recent ASF Infra change impacts what I've observed historically.
 
  Here's what I've seen historically, more or less:
 
  1) Someone expresses interest in a ticket
 
  2) PMC/committers add them to the list of contributors in jira
 
  3) respond to interest informing person of this change and encouraging
 them
  to assign the ticket to themselves
 
  4) work happens on ticket
 
  5) review/commit happens eventually
 
  6) If contributor wants, added to website
 
  7) contributor thanked and encouraged to find more tickets to assign to
  themselves.
 
  Due to a request from Spark, the ASF Jira got changed to default to not
  allow contributors to assign tickets[1].
 
  Before I speak for the PMC and file a follow on to change things back, I
  just wanted a gut check that we like the above as a general approach.
 
 
  [1]: https://issues.apache.org/jira/browse/INFRA-7675
 
  --
  Sean
 

Re: 551 JIRA Tickets Over 2 Years Old

[Corey Nolet]

+1
On Apr 21, 2014 11:47 AM, John Vines vi...@apache.org wrote:

 what about just changing them from being improvements to wishes?


 On Mon, Apr 21, 2014 at 9:26 AM, Bill Havanki bhava...@clouderagovt.com
 wrote:

  +1 to using Won't Fix. Won't can mean won't anytime soon. Labeling
 as
  someday or wishlist or something sounds great to me. The tickets
 remain
  in JIRA, so they can be resurrected if we change our minds or if an eager
  contributor comes along. Nothing is lost.
 
  I'll look into getting our ASF wiki space established if no one is doing
 so
  already. This isn't the only time it's been proposed for use lately.
 
  Thanks to David and everybody doing the spring cleaning.
 
 
  On Mon, Apr 21, 2014 at 1:07 AM, Sean Busbey bus...@cloudera.com
 wrote:
 
   What do we want Jira to represent? I prefer it when projects use Jira
 as
  a
   work queue. If a feature request hasn't gotten interest in 2 years,
 it's
   very unlikely it will suddenly jump to the top of our priority list.
  
   I'm all for suggesting that requestors work on a patch and offering
   feedback to guide them. But if there isn't someone willing to do the
  work,
   the ticket is effectively wontfix. We should make sure there's a
 comment
   that explains that we're open to a feature if someone comes forward to
 do
   the work. We could also add a label so it's easier for the interested
 to
   find them.
  
   There is a cost to keeping these defunct tickets around. Old, untended
   tickets discourage new participants. They make us look unresponsive and
   they represent noise for those trying to look at what's going on.
  
   We do need a place for ideas we find interesting but don't have
 resources
   to handle yet. Many projects request that feature requests start on the
   mailing list to gauge interest. We could just do that, though the mail
   archive is neither super easy to search nor a convenient point of
   reference.
  
   Maybe this would be a good use of our ASF wiki space?
  
  
   On Sat, Apr 19, 2014 at 3:50 PM, Corey Nolet cjno...@gmail.com
 wrote:
  
I agree. Are those tickets really getting in the way? Maybe they
 could
  be
labeled differently to separate them from tech debt, bugs, and other
   active
features?
On Apr 19, 2014 3:51 PM, John Vines vi...@apache.org wrote:
   
 Won't fix isn't accurate though. We're not saying we will reject
 work
   on
 them, they're just not a high priority.


 On Sat, Apr 19, 2014 at 3:03 PM, Christopher ctubb...@apache.org
wrote:

  Resolving them as Won't Fix seems valid to me, if the fact
 that a
  ticket is open helps us track/manage outstanding work. (The
 obvious
  question, then, is does it help in some way?). They can always
 be
  re-opened if we decide it's worth doing.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Sat, Apr 19, 2014 at 1:05 PM, John Vines vi...@apache.org
   wrote:
   Just because they're old doesn't make them invalid. They're
 just
   at a
  lower
   priority. Closing them for the sake of closing them seems like
 a
   bad
  idea.
  
   But if they're actually invalid now, that's an entirely
 different
 notion.
  
   Sent from my phone, please pardon the typos and brevity.
   On Apr 19, 2014 12:42 PM, David Medinets 
   david.medin...@gmail.com

  wrote:
  
   ACCUMULO-483 
  https://issues.apache.org/jira/browse/ACCUMULO-483
   ,
 for
   example, involves creating a purge locality utility. However,
   there
 have
   been no comments since Oct 2012. If the feature has not risen
 in
  priority
   since then, how will it become more important in the future.
Perhaps a
   'good ideas' page or 'roadmap' page could be added to
   http://accumulo.apache.org/? I don't see a benefit to keeping
   these
 old
   tickets.
  
  
   On Sat, Apr 19, 2014 at 10:11 AM, Corey Nolet 
  cjno...@gmail.com
  wrote:
  
Some of these tickets still look like very valid
feature/integration
requests that would still be reasonable to have.
   
See ACCUMULO-74, ACCUMULO-143, ACCUMULO-136, ACCUMULO-211,
  ACCUMULO-483,
ACCUMULO-490, ACCUMULO-508
   
   
   
   
On Sat, Apr 19, 2014 at 9:54 AM, Mike Drob md...@mdrob.com
 
wrote:
   
 Deleting tickets is a no-no, but flagging them is
 certainly
fine.
 On Apr 19, 2014 12:03 AM, David Medinets 
  david.medin...@gmail.com
 wrote:

  Opps. Sorry, I did my filtering badly. There are 68
  tickets
 over 2
years
  old.
 
 
 

   
  
 

   
  
 
 https://issues.apache.org/jira/browse/ACCUMULO-18?jql=project%20%3D%20ACCUMULO%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Patch%20Available%22

Re: 551 JIRA Tickets Over 2 Years Old

[Corey Nolet]

+1 I thought proposal would be good enough to convey the message. Wont
fix is confusing and I could see possible contributors being starred away
by it.
On Apr 21, 2014 1:04 PM, cjno...@gmail.com wrote:

 +1
 On Apr 21, 2014 11:47 AM, John Vines vi...@apache.org wrote:

 what about just changing them from being improvements to wishes?


 On Mon, Apr 21, 2014 at 9:26 AM, Bill Havanki bhava...@clouderagovt.com
 wrote:

  +1 to using Won't Fix. Won't can mean won't anytime soon.
 Labeling as
  someday or wishlist or something sounds great to me. The tickets
 remain
  in JIRA, so they can be resurrected if we change our minds or if an
 eager
  contributor comes along. Nothing is lost.
 
  I'll look into getting our ASF wiki space established if no one is
 doing so
  already. This isn't the only time it's been proposed for use lately.
 
  Thanks to David and everybody doing the spring cleaning.
 
 
  On Mon, Apr 21, 2014 at 1:07 AM, Sean Busbey bus...@cloudera.com
 wrote:
 
   What do we want Jira to represent? I prefer it when projects use Jira
 as
  a
   work queue. If a feature request hasn't gotten interest in 2 years,
 it's
   very unlikely it will suddenly jump to the top of our priority list.
  
   I'm all for suggesting that requestors work on a patch and offering
   feedback to guide them. But if there isn't someone willing to do the
  work,
   the ticket is effectively wontfix. We should make sure there's a
 comment
   that explains that we're open to a feature if someone comes forward
 to do
   the work. We could also add a label so it's easier for the interested
 to
   find them.
  
   There is a cost to keeping these defunct tickets around. Old, untended
   tickets discourage new participants. They make us look unresponsive
 and
   they represent noise for those trying to look at what's going on.
  
   We do need a place for ideas we find interesting but don't have
 resources
   to handle yet. Many projects request that feature requests start on
 the
   mailing list to gauge interest. We could just do that, though the mail
   archive is neither super easy to search nor a convenient point of
   reference.
  
   Maybe this would be a good use of our ASF wiki space?
  
  
   On Sat, Apr 19, 2014 at 3:50 PM, Corey Nolet cjno...@gmail.com
 wrote:
  
I agree. Are those tickets really getting in the way? Maybe they
 could
  be
labeled differently to separate them from tech debt, bugs, and other
   active
features?
On Apr 19, 2014 3:51 PM, John Vines vi...@apache.org wrote:
   
 Won't fix isn't accurate though. We're not saying we will reject
 work
   on
 them, they're just not a high priority.


 On Sat, Apr 19, 2014 at 3:03 PM, Christopher ctubb...@apache.org
 
wrote:

  Resolving them as Won't Fix seems valid to me, if the fact
 that a
  ticket is open helps us track/manage outstanding work. (The
 obvious
  question, then, is does it help in some way?). They can
 always be
  re-opened if we decide it's worth doing.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Sat, Apr 19, 2014 at 1:05 PM, John Vines vi...@apache.org
   wrote:
   Just because they're old doesn't make them invalid. They're
 just
   at a
  lower
   priority. Closing them for the sake of closing them seems
 like a
   bad
  idea.
  
   But if they're actually invalid now, that's an entirely
 different
 notion.
  
   Sent from my phone, please pardon the typos and brevity.
   On Apr 19, 2014 12:42 PM, David Medinets 
   david.medin...@gmail.com

  wrote:
  
   ACCUMULO-483 
  https://issues.apache.org/jira/browse/ACCUMULO-483
   ,
 for
   example, involves creating a purge locality utility. However,
   there
 have
   been no comments since Oct 2012. If the feature has not
 risen in
  priority
   since then, how will it become more important in the future.
Perhaps a
   'good ideas' page or 'roadmap' page could be added to
   http://accumulo.apache.org/? I don't see a benefit to
 keeping
   these
 old
   tickets.
  
  
   On Sat, Apr 19, 2014 at 10:11 AM, Corey Nolet 
  cjno...@gmail.com
  wrote:
  
Some of these tickets still look like very valid
feature/integration
requests that would still be reasonable to have.
   
See ACCUMULO-74, ACCUMULO-143, ACCUMULO-136, ACCUMULO-211,
  ACCUMULO-483,
ACCUMULO-490, ACCUMULO-508
   
   
   
   
On Sat, Apr 19, 2014 at 9:54 AM, Mike Drob 
 md...@mdrob.com
wrote:
   
 Deleting tickets is a no-no, but flagging them is
 certainly
fine.
 On Apr 19, 2014 12:03 AM, David Medinets 
  david.medin...@gmail.com
 wrote:

  Opps. Sorry, I did my filtering badly. There are 68
  tickets
 over 2
years
  old

Re: 551 JIRA Tickets Over 2 Years Old

[Corey Nolet]

Some of these tickets still look like very valid feature/integration
requests that would still be reasonable to have.

See ACCUMULO-74, ACCUMULO-143, ACCUMULO-136, ACCUMULO-211, ACCUMULO-483,
ACCUMULO-490, ACCUMULO-508




On Sat, Apr 19, 2014 at 9:54 AM, Mike Drob md...@mdrob.com wrote:

 Deleting tickets is a no-no, but flagging them is certainly fine.
 On Apr 19, 2014 12:03 AM, David Medinets david.medin...@gmail.com
 wrote:

  Opps. Sorry, I did my filtering badly. There are 68 tickets over 2 years
  old.
 
 
 
 https://issues.apache.org/jira/browse/ACCUMULO-18?jql=project%20%3D%20ACCUMULO%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Patch%20Available%22%29%20AND%20created%20%3C%3D%20-104w%20ORDER%20BY%20key%20ASC
 
 
 
 
  On Sat, Apr 19, 2014 at 12:01 AM, David Medinets
  david.medin...@gmail.comwrote:
 
  
  
 
 https://issues.apache.org/jira/browse/ACCUMULO-551?jql=project%20%3D%20ACCUMULO%20AND%20created%20%3C%3D%20-104w%20ORDER%20BY%20key%20DESC
  
   Is there a technique we can use to curate old tickets? Would anyone
 mind
   if I review them and nominate tickets for closure? I can add a message
  and
   delete any tickets that don't provoke a response. How useful are
 tickets
   that are two years old?
  
 

Re: 551 JIRA Tickets Over 2 Years Old

[Corey Nolet]

I agree. Are those tickets really getting in the way? Maybe they could be
labeled differently to separate them from tech debt, bugs, and other active
features?
On Apr 19, 2014 3:51 PM, John Vines vi...@apache.org wrote:

 Won't fix isn't accurate though. We're not saying we will reject work on
 them, they're just not a high priority.


 On Sat, Apr 19, 2014 at 3:03 PM, Christopher ctubb...@apache.org wrote:

  Resolving them as Won't Fix seems valid to me, if the fact that a
  ticket is open helps us track/manage outstanding work. (The obvious
  question, then, is does it help in some way?). They can always be
  re-opened if we decide it's worth doing.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Sat, Apr 19, 2014 at 1:05 PM, John Vines vi...@apache.org wrote:
   Just because they're old doesn't make them invalid. They're just at a
  lower
   priority. Closing them for the sake of closing them seems like a bad
  idea.
  
   But if they're actually invalid now, that's an entirely different
 notion.
  
   Sent from my phone, please pardon the typos and brevity.
   On Apr 19, 2014 12:42 PM, David Medinets david.medin...@gmail.com
  wrote:
  
   ACCUMULO-483 https://issues.apache.org/jira/browse/ACCUMULO-483,
 for
   example, involves creating a purge locality utility. However, there
 have
   been no comments since Oct 2012. If the feature has not risen in
  priority
   since then, how will it become more important in the future. Perhaps a
   'good ideas' page or 'roadmap' page could be added to
   http://accumulo.apache.org/? I don't see a benefit to keeping these
 old
   tickets.
  
  
   On Sat, Apr 19, 2014 at 10:11 AM, Corey Nolet cjno...@gmail.com
  wrote:
  
Some of these tickets still look like very valid feature/integration
requests that would still be reasonable to have.
   
See ACCUMULO-74, ACCUMULO-143, ACCUMULO-136, ACCUMULO-211,
  ACCUMULO-483,
ACCUMULO-490, ACCUMULO-508
   
   
   
   
On Sat, Apr 19, 2014 at 9:54 AM, Mike Drob md...@mdrob.com wrote:
   
 Deleting tickets is a no-no, but flagging them is certainly fine.
 On Apr 19, 2014 12:03 AM, David Medinets 
  david.medin...@gmail.com
 wrote:

  Opps. Sorry, I did my filtering badly. There are 68 tickets
 over 2
years
  old.
 
 
 

   
  
 
 https://issues.apache.org/jira/browse/ACCUMULO-18?jql=project%20%3D%20ACCUMULO%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Patch%20Available%22%29%20AND%20created%20%3C%3D%20-104w%20ORDER%20BY%20key%20ASC
 
 
 
 
  On Sat, Apr 19, 2014 at 12:01 AM, David Medinets
  david.medin...@gmail.comwrote:
 
  
  
 

   
  
 
 https://issues.apache.org/jira/browse/ACCUMULO-551?jql=project%20%3D%20ACCUMULO%20AND%20created%20%3C%3D%20-104w%20ORDER%20BY%20key%20DESC
  
   Is there a technique we can use to curate old tickets? Would
  anyone
 mind
   if I review them and nominate tickets for closure? I can add a
message
  and
   delete any tickets that don't provoke a response. How useful
 are
 tickets
   that are two years old?
  
 

   
  
 

Re: [VOTE] Accumulo Blog

[Corey Nolet]

I'd like initial posting privileges. Thanks for setting this up!
On Apr 18, 2014 11:23 AM, Bill Havanki bhava...@clouderagovt.com wrote:

 Sure thing Dave, happy to.

 We need to determine an initial list of people with posting privileges.
 I'll start with Dave and myself. If any other PMC member wants in, just let
 me know by COB eastern time, and I'll add you to the infra ticket to
 establish the blog. Don't worry if you miss out, another infra ticket is
 all it takes to get added. (Or, maybe, if you already have a blog account,
 we can add you.)

 Bill H

 On Thu, Apr 17, 2014 at 12:27 PM, dlmar...@comcast.net wrote:

 
  This vote passes with eight +1 votes (5 binding, 3 non-binding) and one
 +0
  vote.
 
  Bill H - I think you volunteered to help with the setup. The instructions
  are located at http://www.apache.org/dev/project-blogs . If you are
  unable to do this let me know.
 
  Thanks,
 
  Dave
 
  - Original Message -
 
  From: dlmar...@comcast.net
  To: dev@accumulo.apache.org
  Sent: Sunday, April 13, 2014 8:11:07 PM
  Subject: [VOTE] Accumulo Blog
 
  I have reviewed the feedback from the proposal thread and consolidated it
  into a set of guidelines for an Accumulo Blog. In accordance with the
  bylaws
  this vote will require Lazy Approval to pass and will remain open for 3
  business days. I'll tally the votes on Thursday morning.
 
 
 
  1. The blog will be hosted on the Apache Blogs site[1].
 
  2. The blog will be set up using the instructions at [2] to enable
  public preview.
 
  3. Proposed blog content will be posted in full-text or link form to
  the dev mailing list.
 
  4. Blog content requires Lazy Approval votes that are open for at
  least 3 days.
 
  5. Content may be cross-posted from other sites provided that the
  content is more than just a link to the other site. The full text of the
  original article is preferred.
 
  6. Content may be cross-posted to other sites provided that there is a
  link back to the Accumulo blog site.
 
 
 
  [1] http://blogs.apache.org/
 
  [2] http://www.apache.org/dev/project-blogs
 
 
 
 
 
 
 


 --
 // Bill Havanki
 // Solutions Architect, Cloudera Govt Solutions
 // 443.686.9283

Re: [VOTE] Accumulo Blog

[Corey Nolet]

+1


On Mon, Apr 14, 2014 at 11:18 AM, Joey Echeverria j...@clouderagovt.comwrote:

 +1 (non-binding)

 --
 Joey Echeverria
 Chief Architect
 Cloudera Government Solutions


 On Mon, Apr 14, 2014 at 11:16 AM, Josh Elser josh.el...@gmail.com wrote:
  +1
 
 
  On 4/13/14, 8:11 PM, dlmar...@comcast.net wrote:
 
  I have reviewed the feedback from the proposal thread and consolidated
 it
  into a set of guidelines for an Accumulo Blog. In accordance with the
  bylaws
  this vote will require Lazy Approval to pass and will remain open for 3
  business days. I'll tally the votes on Thursday morning.
 
 
 
  1.   The blog will be hosted on the Apache Blogs site[1].
 
  2.   The blog will be set up using the instructions at [2] to enable
  public preview.
 
  3.   Proposed blog content will be posted in full-text or link form
 to
  the dev mailing list.
 
  4.   Blog content requires Lazy Approval votes that are open for at
  least 3 days.
 
  5.   Content may be cross-posted from other sites provided that the
  content is more than just a link to the other site. The full text of the
  original article is preferred.
 
  6.   Content may be cross-posted to other sites provided that there
 is
  a
  link back to the Accumulo blog site.
 
 
 
  [1] http://blogs.apache.org/
 
  [2] http://www.apache.org/dev/project-blogs
 
 
 
 
 
 
 

Re: [PROPOSAL] Accumulo Blog

[Corey Nolet]

I'm in favor of full reposts wherever possible. It may be duplication of
content, but it validates for many that the content has been approved by
the community. While the content is being republished, I'm still in favor
of posting a link to the original blog post (if applicable).

I find a blog useful when it's from a reputable source, it's easy to find,
and what I need is right there. I, personally, wouldn't find it as useful
if I searched a blog and then had to go somewhere else to find the actual
content.


On Thu, Apr 10, 2014 at 3:54 PM, Bill Havanki bhava...@clouderagovt.comwrote:

 I think that would be splendid, Don. :)

 I'd be happy to help out with getting this set up. I'm in favor of using
 Apache's blog infrastructure, at least at first, since it's ready to go and
 explicitly for this purpose. I like the sense of place it provides, vs. a
 loose topic on G+ / elsewhere.

 - I'm not a fan of just posting links to articles elsewhere. There should
 be at least a short, complete passage for each post with a link to the full
 thing, if not a full repost.
 - Lazy approval sounds fine to me, since a PMC member has to post the
 content anyway.


 On Thu, Apr 10, 2014 at 3:23 PM, Donald Miner dmi...@clearedgeit.com
 wrote:

  Is this something i can volunteer to help manage if nobody else wants to?
  Do things like set it up, collect blog posts from authors, edit them,
 post
  them, manage the draft and vote process, etc.
 
  Just putting that out there as i see it as a way i can contribute to the
  community and i also personally think it is a good idea.
 
  -d
 
   On Apr 10, 2014, at 1:59 PM, Mike Drob mad...@cloudera.com wrote:
  
   Not sure how I feel about the Google+ community. As the PMC, aren't we
   responsible for brand management?
  
  
   On Thu, Apr 10, 2014 at 1:43 PM, Christopher ctubb...@apache.org
  wrote:
  
   Personally, I'd find it easier to simply suggest people post to a
   common Google+ topic/community, when there's something of community
   interest to blog about, rather than maintain a monolithic blog.
  
   There may be others with the same topic/name, but this one is the one
   I saw first:
   https://plus.google.com/communities/117836301734017142321
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
  
   On Thu, Apr 10, 2014 at 12:12 PM,  dlmar...@comcast.net wrote:
   I am proposing a blog for the project to be hosted on the
   blogs.apache.org site. There was a similar proposal last year on the
  dev
   list [1], but no vote or decision. Apache has a web page with setup
   instructions [2], which also states that the PMC is responsible for
 the
   blog content and for granting write access to the blog. The process
 for
   setting up a blog is easy and defined in [2].
  
  
   To move forward I think we need to resolve some items:
  
   1. The bylaws don't define how to vote on blog content, but the
 default
   vote is in a Lazy Approval fashion, with no defined timeframe. I'm
  thinking
   3 days. Since the PMC is responsible for the content, should we
 enforce
   something different, say, consensus or majority approval from active
 PMC
   members over 3 days?
  
   2. Guidelines for content. If we accept cross-posts from other sites
 or
   blog posts from guest writers (non-contributors, non-committers), what
   rules should be enforced (PMC is responsible for content)? For any
  author,
   can their employer or employer's products be mentioned?
  
   3. Do the articles need to be Apache licensed?
  
   [1]
  
 
 http://mail-archives.apache.org/mod_mbox/accumulo-dev/201311.mbox/%3CCAD-fFU%2B7ZqoVGYMzN%3D09dv9fMSv%2BF32XbsMubsw9HTZ6n155rg%40mail.gmail.com%3E
   [2] http://www.apache.org/dev/project-blogs
  
 



 --
 // Bill Havanki
 // Solutions Architect, Cloudera Govt Solutions
 // 443.686.9283

Re: [PROPOSAL] Accumulo Blog

[Corey Nolet]

Chris, would you be in favor of forwarding blog posts to G+ so that it can
still be provided to that community?


On Thu, Apr 10, 2014 at 4:14 PM, Corey Nolet cjno...@gmail.com wrote:

 I'm in favor of full reposts wherever possible. It may be duplication of
 content, but it validates for many that the content has been approved by
 the community. While the content is being republished, I'm still in favor
 of posting a link to the original blog post (if applicable).

 I find a blog useful when it's from a reputable source, it's easy to find,
 and what I need is right there. I, personally, wouldn't find it as useful
 if I searched a blog and then had to go somewhere else to find the actual
 content.


 On Thu, Apr 10, 2014 at 3:54 PM, Bill Havanki 
 bhava...@clouderagovt.comwrote:

 I think that would be splendid, Don. :)

 I'd be happy to help out with getting this set up. I'm in favor of using
 Apache's blog infrastructure, at least at first, since it's ready to go
 and
 explicitly for this purpose. I like the sense of place it provides, vs. a
 loose topic on G+ / elsewhere.

 - I'm not a fan of just posting links to articles elsewhere. There should
 be at least a short, complete passage for each post with a link to the
 full
 thing, if not a full repost.
 - Lazy approval sounds fine to me, since a PMC member has to post the
 content anyway.


 On Thu, Apr 10, 2014 at 3:23 PM, Donald Miner dmi...@clearedgeit.com
 wrote:

  Is this something i can volunteer to help manage if nobody else wants
 to?
  Do things like set it up, collect blog posts from authors, edit them,
 post
  them, manage the draft and vote process, etc.
 
  Just putting that out there as i see it as a way i can contribute to the
  community and i also personally think it is a good idea.
 
  -d
 
   On Apr 10, 2014, at 1:59 PM, Mike Drob mad...@cloudera.com wrote:
  
   Not sure how I feel about the Google+ community. As the PMC, aren't we
   responsible for brand management?
  
  
   On Thu, Apr 10, 2014 at 1:43 PM, Christopher ctubb...@apache.org
  wrote:
  
   Personally, I'd find it easier to simply suggest people post to a
   common Google+ topic/community, when there's something of community
   interest to blog about, rather than maintain a monolithic blog.
  
   There may be others with the same topic/name, but this one is the one
   I saw first:
   https://plus.google.com/communities/117836301734017142321
  
   --
   Christopher L Tubbs II
   http://gravatar.com/ctubbsii
  
  
   On Thu, Apr 10, 2014 at 12:12 PM,  dlmar...@comcast.net wrote:
   I am proposing a blog for the project to be hosted on the
   blogs.apache.org site. There was a similar proposal last year on the
  dev
   list [1], but no vote or decision. Apache has a web page with setup
   instructions [2], which also states that the PMC is responsible for
 the
   blog content and for granting write access to the blog. The process
 for
   setting up a blog is easy and defined in [2].
  
  
   To move forward I think we need to resolve some items:
  
   1. The bylaws don't define how to vote on blog content, but the
 default
   vote is in a Lazy Approval fashion, with no defined timeframe. I'm
  thinking
   3 days. Since the PMC is responsible for the content, should we
 enforce
   something different, say, consensus or majority approval from active
 PMC
   members over 3 days?
  
   2. Guidelines for content. If we accept cross-posts from other
 sites or
   blog posts from guest writers (non-contributors, non-committers),
 what
   rules should be enforced (PMC is responsible for content)? For any
  author,
   can their employer or employer's products be mentioned?
  
   3. Do the articles need to be Apache licensed?
  
   [1]
  
 
 http://mail-archives.apache.org/mod_mbox/accumulo-dev/201311.mbox/%3CCAD-fFU%2B7ZqoVGYMzN%3D09dv9fMSv%2BF32XbsMubsw9HTZ6n155rg%40mail.gmail.com%3E
   [2] http://www.apache.org/dev/project-blogs
  
 



 --
 // Bill Havanki
 // Solutions Architect, Cloudera Govt Solutions
 // 443.686.9283

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

[Corey Nolet]

+1


On Fri, Apr 4, 2014 at 11:34 AM, Christopher ctubb...@apache.org wrote:

 +1

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Fri, Apr 4, 2014 at 11:33 AM, David Medinets
 david.medin...@gmail.com wrote:
  +1
 
 
  On Fri, Apr 4, 2014 at 11:21 AM, John Vines vi...@apache.org wrote:
 
  This is a proposal to change the Bylaw Change action in the bylaws from
  Majority Approval to Consensus Approval. This is being requested because
  Bylaw changes are a major change to the project and all discussion
 should
  be able to be had without  a borderline majority being able to force
 things
  through.
 
  Specifically, it is the following line which shall be changed
  Modifying BylawsModifying this document.Majority approvalActive PMC
  members7
  to
 
  Modifying BylawsModifying this document.Consensus approvalActive PMC
  members
  7
 
  The current bylaws are visible at
 
  http://accumulo.apache.org/bylaws.html
 
  This vote will be open for 7 days, until 11 April 2014, 15:20 UTC.
 
  Upon successful completion of this vote, the first line of the document
  body
  will be replaced with This is version 2 of the bylaws, ( or This is
  version 3 of the bylaws, if the vote to change Code Changes passes) and
  the aforementioned line will be changed from Majority Approval to
 Consensus
  Approval.
 
  This vote requires majority approval to pass: at least 3 +1 votes and
 more
  +1
  than -1's.
 
  [ ] +1 - I approve of these proposed bylaw changes and accept them for
  the Apache Accumulo project.
  [ ] +0 - I neither approve nor disapprove of these proposed bylaw
 changes,
  but accept them for the Apache Accumulo project.
  [ ] -1 - I do not approve of these proposed bylaw changes and do not
  accept them for the Apache Accumulo project because...
 
  Thank you.
 

Re: [VOTE] Accumulo Bylaws, vote 2

[Corey Nolet]

+1




On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies bimargul...@gmail.comwrote:

 If you're all going to go spelunking in the Apache policy docs,
 perhaps I can help a bit with context.

 The original HTTPD project developed a very specific set of policies
 for controlling  _commits to the code base_. The ballet of
 -1/veto/justification comes out of there. The overall foundation
 policy is an expectation that all projects will apply that same
 approach to commits unless they can state a very good reason to do
 something else.

 Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
 Justification is polite, but not required. Proceeding in the face of a
 -1 is not always a good idea, but the policy envisions it; it
 envisions that someone might vote -1 because they _might prefer_ to
 wait for some other change. But they can just be outvoted.

 Once you get past commits to the codebase and releases, you're more on
 your own in deciding how to decide. The particular case at hand, these
 bylaws, is an interesting one.

 People should be really clear about what they mean when they propose
 consensus as a process. Yes, a consensus process is a process in which
 every member of the community has a veto. However, it is also a
 process in which every member of the community feels a grave weight of
 responsibility in using that veto. Focussing on the veto in a
 consensus process is not a good sign.

 Consensus is a slow, deliberative, process, chosen by communities
 which value group cohesion over most everything else. It is also a
 process that presumes that there is a _status quo_ which is always
 acceptable. The community sticks to the status quo until everyone
 involved is ready to accept some change. This approach to
 decision-making is pretty hard to apply to a new group trying to chart
 a new course.

 It is _not_ foundation policy to expect communities to choose
 full-blown consensus as the predominant process. Typically, in my
 experience, Apache projects do not do full consensus process. Instead,
 they strive to give everyone a voice and seek consensus, but
 eventually decide via a majority of some kind. Most of the time, the
 first part of that (open discussion) achieves a consensus, so that the
 second part of that becomes a formality. However, from time to time,
 the community chooses to decide by majority in order to decide. The
 touchstone of a healthy community is that the minority feel heard and
 not steamrolled.

Re: [VOTE] Accumulo Bylaws, vote 2

[Corey Nolet]

I finally got a chance to fully read through the bylaws and this email
thread.

+1 to approval for the bylaws. Thanks for writing these up!


On Thu, Apr 3, 2014 at 9:59 PM, Sean Busbey busbey+li...@cloudera.comwrote:

 Corey,

 Just for clarity, is your +1 to Benson's sentiment or to the Bylaws Vote
 for this thread?

 -Sean


 On Thu, Apr 3, 2014 at 8:58 PM, Corey Nolet cjno...@gmail.com wrote:

  +1
 
 
 
 
  On Thu, Apr 3, 2014 at 8:45 PM, Benson Margulies bimargul...@gmail.com
  wrote:
 
   If you're all going to go spelunking in the Apache policy docs,
   perhaps I can help a bit with context.
  
   The original HTTPD project developed a very specific set of policies
   for controlling  _commits to the code base_. The ballet of
   -1/veto/justification comes out of there. The overall foundation
   policy is an expectation that all projects will apply that same
   approach to commits unless they can state a very good reason to do
   something else.
  
   Contrarywise, releases cannot be vetoed. A -1 is just a -1. No veto.
   Justification is polite, but not required. Proceeding in the face of a
   -1 is not always a good idea, but the policy envisions it; it
   envisions that someone might vote -1 because they _might prefer_ to
   wait for some other change. But they can just be outvoted.
  
   Once you get past commits to the codebase and releases, you're more on
   your own in deciding how to decide. The particular case at hand, these
   bylaws, is an interesting one.
  
   People should be really clear about what they mean when they propose
   consensus as a process. Yes, a consensus process is a process in which
   every member of the community has a veto. However, it is also a
   process in which every member of the community feels a grave weight of
   responsibility in using that veto. Focussing on the veto in a
   consensus process is not a good sign.
  
   Consensus is a slow, deliberative, process, chosen by communities
   which value group cohesion over most everything else. It is also a
   process that presumes that there is a _status quo_ which is always
   acceptable. The community sticks to the status quo until everyone
   involved is ready to accept some change. This approach to
   decision-making is pretty hard to apply to a new group trying to chart
   a new course.
  
   It is _not_ foundation policy to expect communities to choose
   full-blown consensus as the predominant process. Typically, in my
   experience, Apache projects do not do full consensus process. Instead,
   they strive to give everyone a voice and seek consensus, but
   eventually decide via a majority of some kind. Most of the time, the
   first part of that (open discussion) achieves a consensus, so that the
   second part of that becomes a formality. However, from time to time,
   the community chooses to decide by majority in order to decide. The
   touchstone of a healthy community is that the minority feel heard and
   not steamrolled.
  
 

Re: Accumulo site Bootstrapped

[Corey Nolet]

+1 It is much cleaner. Would be nice (and more maintainable) for sub-menus-
specifically on the versions for docs   packages.


On Wed, Mar 5, 2014 at 8:23 PM, Christopher ctubb...@apache.org wrote:

 +1 for what's been done so far, and for revamped site with 1.6.0 release.

 Rollout sub-menus might be nice. That nav bar is pretty busy.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Wed, Mar 5, 2014 at 6:32 PM, Josh Elser josh.el...@gmail.com wrote:
  Def needs a little more TLC, but using something like Bootstrap instead
 of
  rolling our own is definitely the way to go.
 
  Would be happy to help out here -- maybe we can get a revamped site for
  1.6.0? That'd be pretty boss.
 
 
  On 3/5/14, 5:40 PM, Bill Havanki wrote:
 
  Some folks in the IRC room were discussing how nice the Spark [1] and
 Hue
  [2] sites look compared to ours. While babysitting integration tests, I
  decided to prototype a rework of our site using Twitter Bootstrap [3],
 the
  front-end framework that both of those other sites use.
 
  Here are the pages that I converted.
 
  * http://people.apache.org/~bhavanki/accumulo-bootstrapped/
  *
 
 
 http://people.apache.org/~bhavanki/accumulo-bootstrapped/notable_features.html
  * http://people.apache.org/~bhavanki/accumulo-bootstrapped/source.html
 
  You can navigate between those pages using the left nav menu, but try
  anywhere else and you'll jump out to the production site.
 
  The pages use Bootstrap's own theme, with only very slight modifications
  to
  be close to our own theme. (I actually disabled around 90% of
  accumulo.css.) I kept the page organization like production, although we
  have many other whizbang options with Bootstrap. Some bits I left messy,
  like the nav items for the user manuals, but you should get the idea
  anyway.
 
  Beyond just how it looks, Bootstrap gives you many other capabilities,
  especially responsive display for mobile and tablets, so there's benefit
  to
  a switch beyond just pretty looking boxes.
 
  [1] spark.apache.org
  [2] gethue.com
  [3] getbootstrap.com
 
 

Re: [VOTE] Deprecate mock in 1.6.0

[Corey Nolet]

+1 for keeping a fast and easy (and well documented) mechanism for
debugging iterators. Perhaps the SortedMapiterator is the solution..but the
key words here are 'well documented'

-1 for continuing support a half implemented mock framework that we have to
maintain. It makes code maintenance very hard when you couldnt, for
instance in the 1.3 series, even create a MockBatchDeleter. As Chris
stated, I agree that using the mock in the past had users walking the line
too closely between unit and integration tests. With the mock, I could
write a bunch of fully valid tests against an iterator without the ability
to verify that compactions didn't negatively affect my results. Except for
being fast, the MAC mostly eliminates the need to use the mock for that
kind of test at all while it makes the tests more valid to an actual
runtime environment.

+1 for mocking framework to be used in relevant unit tests. There are times
when a quick and dirty mock is immensely useful and MAC is slow and way
overkill for those tasks. Perhaps it would be worth a ticket to investigate
replacing the current usages of mockAccumulo (I haven't looked in awhile)
with said mocking framework.

On Nov 15, 2013 3:29 PM, Michael Berman mber...@sqrrl.com wrote:

 +1 (not really a voter)

 I think iterator unit tests should use SortedMapIterator, not anything
like
 a full accumulo stack, and I think MAC is far more suitable for
integration
 tests because it actually runs the same code...it's impossible for an
 outsider to tell in which behaviors mock reflects actual accumulo and in
 which it does something totally different.

 I do think MAC needs some help, but I think the process of excising mock
 from our own tests will flesh out what we need there better than anything
 else we could do.


 On Thu, Nov 14, 2013 at 9:20 PM, dlmar...@comcast.net wrote:

  +1
 
 
 
  *From:* Keith Turner [mailto:ke...@deenlo.com]
  *Sent:* Thursday, November 14, 2013 3:42 PM
  *To:* dev@accumulo.apache.org; u...@accumulo.apache.org
  *Subject:* [VOTE] Deprecate mock in 1.6.0
 
 
 
  Should we deprecate mock accumulo for 1.6.0?  This was considered [1]
for
  1.5.0.  I started thinking about this because I never added conditional
  writer to mock.
 
 
 
  [1] : https://issues.apache.org/jira/browse/ACCUMULO-878
 

Re: Accumulo Versions (was Accumulo feature freeze in 1 week)

[Corey Nolet]

bq. For instance, we could establish rules like...

I thought these were already excepted practices. Have they not been
formalized? Other than the backporting, haven't we been following all of
those rules already?


On Fri, Oct 25, 2013 at 10:31 PM, Michael Berman mber...@sqrrl.com wrote:

 
  No public API changes between minor and bugfix releases (API semantic
  changes are okay, if they fix a bug).
  Major features are incorporated into major releases.
  API compatibility is not guaranteed between major releases (deprecated
  methods can be dropped).
  Deprecated API must persist as deprecated through at least one major
  release before removing.
  Minor releases include changes and improvements to existing features,
  but not major new features or drastic changes.


 +1 to all of that!  It's really nice to know that I always want the latest
 available o.o.X and that it's always totally safe to update to, and that
 while things may have changed in the next o.X.o, at least I won't have to
 make any major changes to my client code.  Of course this implies that the
 MSV should increment faster than if often does in these kinds of projects,
 but I think that's ok.  The longer you go without ever bumping the first
 digit, the bigger the change seems like it needs to be to justify finally
 doing so.


 On Fri, Oct 25, 2013 at 9:07 PM, Christopher ctubb...@apache.org wrote:

  You're right, historically, Accumulo has considered y = major, and z =
  minor/bugfix, by convention. This is because our iterative development
  process hasn't really lent itself to feature planning for releases.
  However, in the quoted thread, I was simply providing a definition of
  a term (minor) when I used it, so that I could not possibly be
  misunderstood.
 
  However, since we're on the subject. we need to do better than our
  previous conventions for versioning... because we need to establish a
  better stability in our API contracts. Since not long after we
  switched to using Maven, in the early days of the code, we've at least
  tried to follow maven conventions, and the semantics of versioning is
  one of them. Following it (major.minor.bugfix) more strictly can help
  us make API compatibility guarantees that we can actually enforce, and
  can help with long-term support.
 
  For instance, we could establish rules like:
 
  No public API changes between minor and bugfix releases (API semantic
  changes are okay, if they fix a bug).
  Major features are incorporated into major releases.
  API compatibility is not guaranteed between major releases (deprecated
  methods can be dropped).
  Deprecated API must persist as deprecated through at least one major
  release before removing.
  Minor releases include changes and improvements to existing features,
  but not major new features or drastic changes.
 
  I can't say which specific rules we'd want to establish, but having
  some in place could definitely ease the conflicts between development
  of new features and support for old ones.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Fri, Oct 25, 2013 at 3:43 PM, Sean Busbey bus...@cloudera.com
 wrote:
   On the feature freeze reminder thread, Chris said:
  
   I don't mind putting things off to 1.7 (if necessary). But... if 1.6.0
   isn't sufficiently feature rich, there's not really a reason to
   release it just yet... until those features are ready. That said, I do
   think there'll be enough features in 1.6.0 to release it as a minor
   release, if we're interpreting the version as the standard
   major.minor.bugfix scheme, even if we end up pushing some stuff
   off to 1.7.
  
   I didn't want to derail that thread, but this does not line up with
 what
   I've seen in Accumulo. (Though I agree that it is a common numbering
   scheme[1])
  
   The Accumulo release guide[2] doesn't specify how minor and major
  turn
   into positions in the version number. However, the git workflow
 guide[3]
   does, and basically says that Accumulo uses
  
   x.y.z
  
   y = major
   z = minor
  
   This also lines up with my understanding of previous Accumulo releases
  and
   cross-compatibility amongst them.
  
  
   [1]: http://semver.org/spec/v2.0.0.html
   [2]: http://accumulo.apache.org/governance/releasing.html
   [3]: http://accumulo.apache.org/git.html#release-management
  
   --
   Sean
 

Re: Accumulo Versions (was Accumulo feature freeze in 1 week)

[Corey Nolet]

Adding to above- I've been seeing the minor as the bugfix and the major as
the new feature and possible API changes version. I'm all for following
Maven's lead but what would that transition look like? Does that mean there
would be a 2.0 coming out soon?


On Fri, Oct 25, 2013 at 10:44 PM, Corey Nolet cjno...@gmail.com wrote:


 bq. For instance, we could establish rules like...

 I thought these were already excepted practices. Have they not been
 formalized? Other than the backporting, haven't we been following all of
 those rules already?


 On Fri, Oct 25, 2013 at 10:31 PM, Michael Berman mber...@sqrrl.comwrote:

 
  No public API changes between minor and bugfix releases (API semantic
  changes are okay, if they fix a bug).
  Major features are incorporated into major releases.
  API compatibility is not guaranteed between major releases (deprecated
  methods can be dropped).
  Deprecated API must persist as deprecated through at least one major
  release before removing.
  Minor releases include changes and improvements to existing features,
  but not major new features or drastic changes.


 +1 to all of that!  It's really nice to know that I always want the latest
 available o.o.X and that it's always totally safe to update to, and that
 while things may have changed in the next o.X.o, at least I won't have to
 make any major changes to my client code.  Of course this implies that the
 MSV should increment faster than if often does in these kinds of projects,
 but I think that's ok.  The longer you go without ever bumping the first
 digit, the bigger the change seems like it needs to be to justify finally
 doing so.


 On Fri, Oct 25, 2013 at 9:07 PM, Christopher ctubb...@apache.org wrote:

  You're right, historically, Accumulo has considered y = major, and z =
  minor/bugfix, by convention. This is because our iterative development
  process hasn't really lent itself to feature planning for releases.
  However, in the quoted thread, I was simply providing a definition of
  a term (minor) when I used it, so that I could not possibly be
  misunderstood.
 
  However, since we're on the subject. we need to do better than our
  previous conventions for versioning... because we need to establish a
  better stability in our API contracts. Since not long after we
  switched to using Maven, in the early days of the code, we've at least
  tried to follow maven conventions, and the semantics of versioning is
  one of them. Following it (major.minor.bugfix) more strictly can help
  us make API compatibility guarantees that we can actually enforce, and
  can help with long-term support.
 
  For instance, we could establish rules like:
 
  No public API changes between minor and bugfix releases (API semantic
  changes are okay, if they fix a bug).
  Major features are incorporated into major releases.
  API compatibility is not guaranteed between major releases (deprecated
  methods can be dropped).
  Deprecated API must persist as deprecated through at least one major
  release before removing.
  Minor releases include changes and improvements to existing features,
  but not major new features or drastic changes.
 
  I can't say which specific rules we'd want to establish, but having
  some in place could definitely ease the conflicts between development
  of new features and support for old ones.
 
  --
  Christopher L Tubbs II
  http://gravatar.com/ctubbsii
 
 
  On Fri, Oct 25, 2013 at 3:43 PM, Sean Busbey bus...@cloudera.com
 wrote:
   On the feature freeze reminder thread, Chris said:
  
   I don't mind putting things off to 1.7 (if necessary). But... if
 1.6.0
   isn't sufficiently feature rich, there's not really a reason to
   release it just yet... until those features are ready. That said, I
 do
   think there'll be enough features in 1.6.0 to release it as a minor
   release, if we're interpreting the version as the standard
   major.minor.bugfix scheme, even if we end up pushing some stuff
   off to 1.7.
  
   I didn't want to derail that thread, but this does not line up with
 what
   I've seen in Accumulo. (Though I agree that it is a common numbering
   scheme[1])
  
   The Accumulo release guide[2] doesn't specify how minor and major
  turn
   into positions in the version number. However, the git workflow
 guide[3]
   does, and basically says that Accumulo uses
  
   x.y.z
  
   y = major
   z = minor
  
   This also lines up with my understanding of previous Accumulo releases
  and
   cross-compatibility amongst them.
  
  
   [1]: http://semver.org/spec/v2.0.0.html
   [2]: http://accumulo.apache.org/governance/releasing.html
   [3]: http://accumulo.apache.org/git.html#release-management
  
   --
   Sean
 

Re: Issues running Minicluster in o.a.a.start.Main

[Corey Nolet]

Looking at the commit history in master using gitk/gitx shows duplicated
history. It looks like January through July 2013 occur at least twice in
the commit history (with 2012 in between them). I'm suspecting this may
have been why bisect wasn't working for me



On Wed, Oct 9, 2013 at 1:25 PM, Keith Turner ke...@deenlo.com wrote:

 On Tue, Oct 8, 2013 at 9:45 PM, Corey Nolet cjno...@gmail.com wrote:

  Keith,
 
  It appears that the proxy's useMini and the minicluster command broke
  somewhere between
 
  1edccf6b30541841bb08329317c6289aca8c8d73
  ACCUMULO-1707 applying Steve's patch
 
  and
 
  98d7a9efc6d07e71d3803b3830bf9dc9ce8dec9d
  ACCUMULO-1558 made import table fail when files do not exist
 
  There was some weird merging happening during that sequence of commits.
 At
  some point it looks like the master pom was set to version 1.5.1. If a
 bug
  was fixed in this sequence of commits and the fix inherently broke the
  commands because they didn't belong in start.Main to begin with, I'm
  thinking it would probably be best to take the useMini property out of
 the
  proxy and the minicluster command out of start.Main.
 
  If a bug was introduced, I'd like to get a ticket up for it.
 

 Yeah, go ahead and open a ticket.


 
 
 
 
 
  On Tue, Oct 8, 2013 at 12:02 AM, Corey Nolet cjno...@gmail.com wrote:
 
   Keith,
  
   You are right- I mistyped. I meant Main.err not Master.err. I just
   verified this feature worked during the time of this
   commit: 6965a8aaa2f53ec796a3487c1639affe0dfc6bfa.
  
  
   On Mon, Oct 7, 2013 at 11:39 PM, Keith Turner ke...@deenlo.com
 wrote:
  
   I just tried running accumulo miniscluster and saw the same thing.
   But
   in Main.err, not Master.err are you sure you saw this in Master.err?
  
   Has this ever worked?   By default the accumulo scripts construct a
 very
   minimal classpath w/ accumulo-start.jar,  log4j-1.2.15.jar, and the
 conf
   dir.   If you modify the MAC exec method to print the classpath it
 uses
  to
   start a java process, then you can see this.   MAC makes the
 assumption
   that everything it needs is on the Java classpath, which is true when
  its
   run from Maven or Eclipse.  However when its run from the accumulo
   scripts,
   this is not true.
  
   Also, for some reason MAC starts zookeeper using Accumulo start main.
  I
   have no idea why its doing this.  Even if it was not doing this, I
 think
   would fail in different way (i.e. instead of not finding VFS it would
  not
   find zookeeper class).
  
   Are you familiar with accumulo start module?
  
  
  
  
  
   On Mon, Oct 7, 2013 at 7:36 AM, Corey Nolet cjno...@gmail.com
 wrote:
  
The MiniAccumuloRunner class that's wired up to o.o.a.start.Main.
   
I was specifically wondering if anyone else is experiencing issues
   running
'accumulo minicluster' as both the proxy with useMini=true and the
minicluster command seem broken for me. I'm building from remote
 HEAD
  in
master.
On Oct 6, 2013 11:32 AM, John Vines jvi...@gmail.com wrote:
   
 How are you running minicluster?


 On Sun, Oct 6, 2013 at 8:36 AM, Corey Nolet cjno...@gmail.com
   wrote:

  I'm having issues running the minicluster both in the 'accumulo
   proxy
-p
  proxy.properties' and via 'accumulo minicluster'. It looks like
  the
  Zookeeper process is not starting and the MAC is going into an
   infinite
  loop waiting for it to start.
 
  I checked the Master.err logs for the minicluster command and I
  see
   the
  following:
 
  Uncaught exception: java.lang.NoClassDefFoundError:
  org/apache/commons/vfs2/impl/VFSClassLoader
  java.lang.NoClassDefFoundError:
 org/apache/commons/vfs2/impl/VFSClassLoader
  at java.lang.Class.getDeclaredMethods0(Native Method)
  at java.lang.Class.privateGetDeclaredMethods(Class.java:2521)
  at java.lang.Class.getMethod0(Class.java:2764)
  at java.lang.Class.getMethod(Class.java:1653)
  at org.apache.accumulo.start.Main.main(Main.java:42)
  Caused by: java.lang.ClassNotFoundException:
  org.apache.commons.vfs2.impl.VFSClassLoader
  at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
  at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
  ... 5 more
 
 
  the commons-vfs2.jar is in Accumulo's lib directory. I'm using
   Hadoop
  1.2.1.
 



 --
 Cheers
 ~John