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: 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: [VOTE] Accumulo Bylaws - Bylaw Change Changes

[Corey Nolet]

+1


On Fri, Apr 4, 2014 at 11:34 AM, Christopher  wrote:

> +1
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Fri, Apr 4, 2014 at 11:33 AM, David Medinets
>  wrote:
> > +1
> >
> >
> > On Fri, Apr 4, 2014 at 11:21 AM, John Vines  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: [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 wrote:

> 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  >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  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 
> > 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,   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  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 
> wrote:
>
>> 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 > >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  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 
>> > 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,   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 Blog

[Corey Nolet]

+1


On Mon, Apr 14, 2014 at 11:18 AM, Joey Echeverria wrote:

> +1 (non-binding)
>
> --
> Joey Echeverria
> Chief Architect
> Cloudera Government Solutions
>
>
> On Mon, Apr 14, 2014 at 11:16 AM, Josh Elser  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: [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"  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,  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: 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  wrote:

> Deleting tickets is a no-no, but flagging them is certainly fine.
> On Apr 19, 2014 12:03 AM, "David Medinets" 
> 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
> > wrote:
> >
> > >
> > >
> >
> 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"  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  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  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" 
> > 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 
> > 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  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
> > >> > > > wrote:
> > >> > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> 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]

+1
On Apr 21, 2014 11:47 AM, "John Vines"  wrote:

> what about just changing them from being improvements to wishes?
>
>
> On Mon, Apr 21, 2014 at 9:26 AM, Bill Havanki  >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 
> 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 
> 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"  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 
> > > > 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 
> > > 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:
> > > > > > >
&g

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"  wrote:
>
>> what about just changing them from being improvements to wishes?
>>
>>
>> On Mon, Apr 21, 2014 at 9:26 AM, Bill Havanki > >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 
>> 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 
>> 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"  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 > >
>> > > > 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 
>> > > wrote:
>> > > > > > > Just because they're old doesn't make them invalid. They're
>> just
>> > > at a
>> > > > > > lower
>> > > 

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  wrote:

> Yes, restore the old behavior
>
>
> On Wed, May 14, 2014 at 4:38 PM, Sean Busbey  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: 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 
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
> > 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: 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  wrote:

> On Thu, Jun 12, 2014 at 11:44 PM, Vicky Kak  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 
> > 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 *
> > >
> >
>

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

Tablet server thrift issue

[Corey Nolet]

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]

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

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  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  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 
>>> 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
>>>>
>>>&g

Re: Time to release 1.6.1?

[Corey Nolet]

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  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  wrote:
>>
>>  On Thu, Jun 19, 2014 at 11:46 AM, Josh Elser 
>>> 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 
>>>>> 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: 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  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 
> 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 
> 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 
> > 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 
> > >>>> 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 
> > >>>>>>> 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: [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  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  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 

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

>>>
>>

[VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

Devs,

Please consider the following candidate for Apache Accumulo 1.6.1

Branch: 1.6.1-rc1
SHA1: 88c5473b3b49d797d3dabebd12fe517e9b248ba2
Staging Repository:
*https://repository.apache.org/content/repositories/orgapacheaccumulo-1017/
*

Source tarball:
*http://repository.apache.org/content/repositories/orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.1/accumulo-1.6.1-src.tar.gz
*
Binary tarball:
*http://repository.apache.org/content/repositories/orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.1/accumulo-1.6.1-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 188 issues resolved
*https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=CHANGES;h=91b9d31e3b9dc53f1a576cc49bbc061919eb0070;hb=1.6.1-rc1
*

Testing: All unit and functional tests are passing.

Vote will be open until Thursday, September 25th 12:00AM UTC (9/24 8:00PM
ET, 9/24 5:00PM PT)

Re: [VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

Yeah I'll push it tonight.

On Mon, Sep 22, 2014 at 4:28 PM, Josh Elser  wrote:

> This appears to have been a snafu (related to the push-screwup). I'll try
> to restore if I have the branch locally, but you might have to re-push your
> branch, Corey (or anyone else who has the SHA1 listed in his original VOTE
> email).
>
>
> On 9/22/14, 1:26 PM, Josh Elser wrote:
>
>> Corey, I don't see the branch. Did you forget to push?
>>
>> On 9/19/14, 10:49 PM, Corey Nolet wrote:
>>
>>> Devs,
>>>
>>> Please consider the following candidate for Apache Accumulo 1.6.1
>>>
>>> Branch: 1.6.1-rc1
>>> SHA1: 88c5473b3b49d797d3dabebd12fe517e9b248ba2
>>> Staging Repository:
>>> *https://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/
>>>
>>> <https://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/>*
>>>
>>>
>>> Source tarball:
>>> *http://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.
>>> 1/accumulo-1.6.1-src.tar.gz
>>>
>>> <http://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.
>>> 1/accumulo-1.6.1-src.tar.gz>*
>>>
>>> Binary tarball:
>>> *http://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.
>>> 1/accumulo-1.6.1-bin.tar.gz
>>>
>>> <http://repository.apache.org/content/repositories/
>>> orgapacheaccumulo-1017/org/apache/accumulo/accumulo/1.6.
>>> 1/accumulo-1.6.1-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 188 issues resolved
>>> *https://git-wip-us.apache.org/repos/asf?p=accumulo.git;
>>> a=blob;f=CHANGES;h=91b9d31e3b9dc53f1a576cc49bbc061919eb0070;hb=1.6.1-rc1
>>>
>>> <https://git-wip-us.apache.org/repos/asf?p=accumulo.git;
>>> a=blob;f=CHANGES;h=91b9d31e3b9dc53f1a576cc49bbc061919eb0070;hb=1.6.1-rc1
>>> >*
>>>
>>>
>>> Testing: All unit and functional tests are passing.
>>>
>>> Vote will be open until Thursday, September 25th 12:00AM UTC (9/24 8:00PM
>>> ET, 9/24 5:00PM PT)
>>>
>>>

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  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  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.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  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  wrote:
>
> > On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks 
> > 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 
> > 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: [VOTE] Apache Accumulo 1.6.1 RC1

[Corey Nolet]

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  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 Turner  wrote:
>>
>>  On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks
>>> 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

>>> 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: [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 
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  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 
> 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 Turner
> > 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
> > >>>>
> > >>> 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  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  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 
> 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 
> > 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 
> > > 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 Penning
> > > 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  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 
> 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 Nolet
> > 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
> > >>>>
> > >>> 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 Turner
> > >>>>>>
> > >>>>> wrote:
> > >>>>
> > >>>>>   On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks<
> > >

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

[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: 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  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
>>
>

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

[Corey Nolet]

Yeah the reason ask about having the community support it is because the
thrift interfaces are all internal workings, thus, code other than the
client API should probably be maintained internally. This will add a slight
overhead to development and maintenance of these thrift services because
more implementations will now need to be kept up to date and modified when
changes need to be implemented.

Not saying it should be a showstopper, just pointing it out.

On Mon, Oct 6, 2014 at 4:15 PM, David Medinets 
wrote:

> How far away from the theoretical maximum rate is the thrift protocol?
> What kind of gain is expected from the native C++ approach?
>
> On Sat, Oct 4, 2014 at 12:56 PM, 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
>

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  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 Elser
>> wrote:
>>
>>
>>> Sean Busbey wrote:
>>>
>>>  On Wed, Nov 12, 2014 at 12:31 PM, Josh Elser
 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  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 Elser  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 Elser
>>>> wrote:
>>>>
>>>>
>>>>  Sean Busbey wrote:
>>>>>
>>>>>   On Wed, Nov 12, 2014 at 12:31 PM, Josh Elser
>>>>>
>>>>>> 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]

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 
wrote:

> +1
> On Nov 14, 2014 11:18 AM, "Keith Turner"  wrote:
>
> > On Wed, Nov 12, 2014 at 4:52 PM, Corey Nolet  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 
> > 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 Elser
> > > 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 Elser >
> > > >>>> wrote:
> > > >>>>
> > > >>>>
> > > >>

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  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  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: [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  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 
> 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: [DISCUSS] Bylaws Change - Majority Approval for Code Changes

[Corey Nolet]

Jeremy,

The PMC boards in ASF are required to look out for the long term health of
the entire project. This is why the conversation of consensus can be a
touchy one and a hard one to agree on. If a single PMC member vetos a code
change, can that single member stop the code from being changed or could
majority overrule the veto. It's going to be a complicated discussion.

On Wed, Nov 26, 2014 at 1:42 PM, Corey Nolet  wrote:

> Jeremy,
>
> The PMC boards in ASF are re
>
> On Wed, Nov 26, 2014 at 1:18 PM, Jeremy Kepner  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 
>> 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]

+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  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, Christopher  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, Christopher
>>> wrote:
>>>
>>>  On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey

>>> wrote:
>>>
 Responses to a few things below.
>
>
> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss
>
 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
>>>
>> 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, Christopher
>
 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
>>>
>> purpo

Re: [VOTE] adoption of semver

[Corey Nolet]

+1

On Tue, Dec 9, 2014 at 2:56 PM, David Medinets 
wrote:

> +1
>
> On Tue, Dec 9, 2014 at 2:22 PM, Sean Busbey  wrote:
> > +0
> >
> > Just for clarification, this vote isn't defining what the semver applies
> > to? I presume that means the same things already covered in "Section 9
> API"
> > from the README[1]?
> >
> > [1]:
> >
> https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;h=a9f4645186c6431a0b68d115c7a92d18753c36f1;hb=HEAD
> >
> > On Tue, Dec 9, 2014 at 1:07 PM, John Vines  wrote:
> >
> >> +1
> >>
> >> On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner  wrote:
> >>
> >> > +1
> >> >
> >> > On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi 
> >> wrote:
> >> >
> >> > > I would like to call a vote on adopting semantic versioning (
> >> > > http://semver.org/) for future releases.
> >> > >
> >> > > This vote is subject to majority approval and will remain open for
> 72
> >> > > hours.
> >> > >
> >> > > +1: Adopt semantic versioning for all future releases
> >> > > +0: Don't care
> >> > > -1: Do not adopt semantic versioning because ...
> >> > >
> >> > > Here is my +1.
> >> > >
> >> > > Billie
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Sean
>

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  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 Pyeron 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: accumulo Scanner

[Corey Nolet]

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

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

On Thu, Dec 11, 2014 at 10:24 PM, 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 (Entry 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 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 
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: 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  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  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: 1.6.2 candidates

[Corey Nolet]

I'll cut one tonight

On Wed, Dec 17, 2014 at 1:52 PM, Christopher  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 
> 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  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 
> > 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 
> > > 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: 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  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  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 Nolet
> 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: 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: 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/table

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]

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

Not sure why intelli-j defaults to this behavior but it's fixed.


- Corey


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


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]

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

> 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. 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.
> 
> Corey Nolet wrote:
> 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
> 
> kturner wrote:
> > unless Keith has multiple profiles for his import orders
> 
> I use two eclipse workspaces w/ different config, one for Fluo and one 
> for Accumulo.  I try my best to avoid making changes unrelated to the task I 
> am working.

Christopher, when I read over your comment early this morning, I read it as 
"Import order is something that our formatting standards don't even address,  
[maybe it's time we address them.]" I referenced what we did on Fluo just to 
present the idea of putting those standards on the site, not to say any they 
need to be changed.

> I use two eclipse workspaces w/ different config, one for Fluo and one for 
> Accumulo

It makes sense now. I was wondering why the deltas were only happening for me. 
I just assumed Mike and yourself were using the defaults that were already 
being used in Accumulo.


- 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/s

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

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

[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: [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"  wrote:

> On Wed, Jan 21, 2015 at 3:08 AM, Sean Busbey  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 
> 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
> >
>

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"  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  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 
> wrote:
> >
> > > On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey 
> > wrote:
> > >
> > > > On Wed, Jan 21, 2015 at 6:57 AM,  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]

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

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

On Thu, Jan 22, 2015 at 2:25 PM, Christopher  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  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"  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 
> 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 
> > > wrote:
> > > >
> > > > > On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey  >
> > > > wrote:
> > > > >
> > > > > > On Wed, Jan 21, 2015 at 6:57 AM,  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'll add this to my docs for bugfix releases- thanks!

On Fri, Jan 23, 2015 at 1:05 AM, Sean Busbey  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  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, Christopher
> 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
> 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"  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
> >>>>>
> >>>> 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
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, Jan 21, 2015 at 11:05 AM, Sean Busbey >>>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Wed, Jan 21, 2015 at 6:57 AM,  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: 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: 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/#review69571
---

Ship it!


Ship It!

- 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"  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 > <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 RC2

[Corey Nolet]

Christopher,

I see what I did in regards to the commit hash- I based the rc2  branch off
of the branch I ran the maven release plugin from instead of basing it off
the tag which was created.

On Sun, Jan 25, 2015 at 3:38 PM, Corey Nolet  wrote:

> Forwarding discussions to dev.
> On Jan 25, 2015 3:22 PM, "Josh Elser"  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 >> <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: 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  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
> 
>
> 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
> >
> >
>
>

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:53 p.m.)


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


Changes
---

Can still use getConfiguration() in InputFormatBase 


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

[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: [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"  wrote:

> -1 because of ACCUMULO-3541
>
> On Wed, Jan 28, 2015 at 2:38 AM, 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"  wrote:

> On Wed, Jan 28, 2015 at 2:30 PM, Sean Busbey  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  > <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=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  > > <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=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]

> 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  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: 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  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  wrote:
>
> > On Thu, Jan 29, 2015 at 7:27 PM, Corey Nolet  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 
> > 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)
> > > >>
> > > >>
> > >
> >
>

[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: [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  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  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]

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

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

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  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 Turner  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  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  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  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 Turner  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
>>>> 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)
>>>>>
>>>>>
>>>
>