Re: Review Request 19804: ACCUMULO-2519 Aborts upgrade if there are Fate transactions from an old version.

> On March 29, 2014, 12:26 a.m., kturner wrote: > > server/src/main/java/org/apache/accumulo/server/master/Master.java, line 313 > > > > > > I think this check can cause problems. Master.run() starts > > StatusThread

Re: [DISCUSS] MiniAccumuloCluster goals and approach

I'll have something integrated to 1.6.0 this weekend. Something concrete may help to firm everyone's opinion. On Mar 28, 2014 5:54 PM, "Christopher" wrote: > If it's marked Experimental in the javadocs, I think it may be fine. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > O

Re: Review Request 19804: ACCUMULO-2519 Aborts upgrade if there are Fate transactions from an old version.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19804/#review38972 --- server/src/main/java/org/apache/accumulo/server/master/Master.java

Re: [DISCUSS] MiniAccumuloCluster goals and approach

If it's marked Experimental in the javadocs, I think it may be fine. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Mar 28, 2014 at 4:50 PM, Sean Busbey wrote: > If the new interface is not in the public API, then I think adding it > (without deprecating MAC) is fine. > > That w

Review Request 19804: ACCUMULO-2519 Aborts upgrade if there are Fate transactions from an old version.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19804/ --- Review request for accumulo and kturner. Bugs: ACCUMULO-2519 https://issues

Re: [DISCUSS] MiniAccumuloCluster goals and approach

If the new interface is not in the public API, then I think adding it (without deprecating MAC) is fine. That way it can evolve if needed and we can add it to the public API on a later release. On Fri, Mar 28, 2014 at 3:39 PM, Christopher wrote: > But... without more time to fully develop the

Re: Review Request 19749: ACCUMULO-2566 Hadoop reflection for TeraSortIngest

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19749/#review38944 --- Ship it! Ship It! - Sean Busbey On March 27, 2014, 8:25 p.m., Mi

Re: Review Request 19716: ACCUMULO-2564 Backport changes to unify Hadoop 1/2

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19716/#review38943 --- Ship it! Ship It! - Sean Busbey On March 28, 2014, 8:34 p.m., Mi

Re: [DISCUSS] MiniAccumuloCluster goals and approach

But... without more time to fully develop the requirements for the interface, with a few implementations, it's probably going to change anyway. I think even adding the interface could complicate the follow-on work. But... *shrug* maybe you can have guarantees that the interface will stay as is

Re: Review Request 19716: ACCUMULO-2564 Backport changes to unify Hadoop 1/2

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19716/ --- (Updated March 28, 2014, 8:34 p.m.) Review request for accumulo, Adam Fuchs, Se

Re: Review Request 19716: ACCUMULO-2564 Backport changes to unify Hadoop 1/2

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19716/ --- (Updated March 28, 2014, 8:33 p.m.) Review request for accumulo, Adam Fuchs, Se

Re: [DISCUSS] MiniAccumuloCluster goals and approach

I think this is better reserved for a version later than 1.6.0. It's an 11th hour change in addition to being a large overhaul of the interfaces to support functionality we never intended for 1.6.0. On Fri, Mar 28, 2014 at 4:04 PM, Josh Elser wrote: > Forgot to also add, that I would add the ex

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Filed as ACCUMULO-2590 https://issues.apache.org/jira/browse/ACCUMULO-2590 On Fri, Mar 28, 2014 at 2:56 PM, Josh Elser wrote: > Can someone make a 1.6 ticket to clarify this confusion in the README? > > There is undeniable confusion to date but it doesn't seem like anyone minds > including pub

Re: [DISCUSS] MiniAccumuloCluster goals and approach

Forgot to also add, that I would add the experimental annotation to alleviate confusion. The already mocked minimum set of methods on the interface which I posted to github Is a first pass. If we miss something that is in fact common, we can add it later, anything else is likely destined for the i

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Can someone make a 1.6 ticket to clarify this confusion in the README? There is undeniable confusion to date but it doesn't seem like anyone minds including public nested classes either. I'd have to scan over the public members of these classes to make sure we don't inadvertantly advertise somethi

Re: [DISCUSS] MiniAccumuloCluster goals and approach

On Fri, Mar 28, 2014 at 3:14 PM, Josh Elser wrote: > Not even the addition of a new interface, Christopher? I'd very much like > to have an interface that we can get in 1.6.0 at a minimum. I wouldn't even > push for any deprecation of what's currently in place. > W/o deprecation it seems very co

Re: [DISCUSS] ACCUMULO-905 (jdk7)

+1 On Fri, Mar 28, 2014 at 3:30 PM, Josh Elser wrote: > Clarification on javadocs, the generated 1.5.1 javadocs were not vulnerable > and required no patching. > > That said, I'm still in favor of bumping to jdk7. > On Mar 28, 2014 11:36 AM, "Christopher" wrote: > > > I want to bump the minimu

Re: [DISCUSS] ACCUMULO-905 (jdk7)

Clarification on javadocs, the generated 1.5.1 javadocs were not vulnerable and required no patching. That said, I'm still in favor of bumping to jdk7. On Mar 28, 2014 11:36 AM, "Christopher" wrote: > I want to bump the minimum supported version of Java to 7 for the next > version after the 1.6.

Re: Review Request 19716: ACCUMULO-2564 Backport changes to unify Hadoop 1/2

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19716/ --- (Updated March 28, 2014, 7:23 p.m.) Review request for accumulo, Adam Fuchs, Se

Re: [VOTE] Apache Accumulo 1.5.1-RC3

That was my interpretation as well. On Fri, Mar 28, 2014 at 3:13 PM, Mike Drob wrote: > Public members, including inner classes, of public classes seem like they > are de facto Public API. > > > On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser wrote: > > > Yes. This is exactly what was discussed ea

Re: [DISCUSS] MiniAccumuloCluster goals and approach

Not even the addition of a new interface, Christopher? I'd very much like to have an interface that we can get in 1.6.0 at a minimum. I wouldn't even push for any deprecation of what's currently in place. On Mar 28, 2014 10:02 AM, "Christopher" wrote: > I don't think any of this should be done fo

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Public members, including inner classes, of public classes seem like they are de facto Public API. On Fri, Mar 28, 2014 at 3:11 PM, Josh Elser wrote: > Yes. This is exactly what was discussed earlier in this thread. > On Mar 28, 2014 10:35 AM, "Christopher" wrote: > > > That README was probabl

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Yes. This is exactly what was discussed earlier in this thread. On Mar 28, 2014 10:35 AM, "Christopher" wrote: > That README was probably written without consideration of the > implication for inner-classes. There is a strict interpretation, yes, > but the intent is certainly not clear. > > -- >

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Ah, I missed the recursiveness of the o.a.a.c.c. But, like I mentioned in the other message, I don't think binary compat was achieved, but the package name, constructors, and methods existing in 1.5.0 were maintained AFAIK. Are we asserting binary compat here as well? I'm trying to understand

Re: Review Request 19790: ACCUMULO-378 Design document

> On March 28, 2014, 6:06 p.m., Mike Drob wrote: > > I did not see any considerations for dealing with limited WAN capacity. If > > data ingest is local to the master, then it is feasible that the ingest > > bandwidth is much higher than can be efficiently acheived between e.g. > > Oregon and

Re: Review Request 19790: ACCUMULO-378 Design document

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19790/#review38927 --- docs/src/main/resources/design/ACCUMULO-378-design.mdtext

[DISCUSS] ACCUMULO-905 (jdk7)

I want to bump the minimum supported version of Java to 7 for the next version after the 1.6.x series. (Currently, this is tracked in JIRA as 1.7.0, and the master branch in git). We've discussed this in detail for 1.5.0 and 1.6.0, and it has been postponed for various reasons. I'd rather not reha

Re: Review Request 19592: ACCUMULO-2470 - unit tests for server/base

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19592/#review38928 --- Ship it! Ship It! - Mike Drob On March 25, 2014, 5:44 p.m., Bill

Re: Review Request 19790: ACCUMULO-378 Design document

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19790/#review38925 --- docs/src/main/resources/design/ACCUMULO-378-design.mdtext

Re: Review Request 19790: ACCUMULO-378 Design document

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19790/#review38922 --- I did not see any considerations for dealing with limited WAN capaci

Re: [VOTE] Apache Accumulo 1.5.1-RC3

You could use listSplits() and then tablet locator http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/client/impl/TabletLocator.html On Fri, Mar 28, 2014 at 9:49 AM, Donald Miner wrote: > I'm starting to dig around for a workaround and figured someone might be > able to help me rig

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Devil's advocate: RangeInputSplit isn't part of the public API either, so it comes with the same risks that TabletLocator would. It sounds more like the definition of "public api" should be expanded to prevent this in future cases. I need to look at what exactly broke for Don. On 3/28/14, 9:1

Re: [VOTE] Apache Accumulo 1.5.1-RC3

The README is already clear that everything under those packages is included, with the exception of the impl pacakge. In my reading, that means all Classes and Interfaces in any package under the client package, and everything in those classes that is at either public and protected access. I gues

Re: [VOTE] Apache Accumulo 1.5.1-RC3

I'm starting to dig around for a workaround and figured someone might be able to help me right away. In digging deeper, we were using RangeInputSplit because it gave us the splits AND the locations. We use the locations for some data locality placing in our distributed application. listSplits only

Review Request 19790: ACCUMULO-378 Design document

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19790/ --- Review request for accumulo. Bugs: ACCUMULO-378 https://issues.apache.org/j

Re: [DISCUSS] MiniAccumuloCluster goals and approach

I've been watching the conversation on the side, but I wanted to mention that it seems the focus isn't so much on "mini" clusters anymore. You're thinking of programmatic cluster management, whether one node or many. The idea of a basic cluster management interface, with MAC as an implementation, i

Re: [DISCUSS] Reviewing design documents

Could this be a good test case for Gerrit? On Fri, Mar 28, 2014 at 12:23 AM, Sean Busbey wrote: > Aside from the occasional stability problem, I really like the idea of > using ReviewBoard. It has the best option for in-context commenting amongst > our options at Apache AFAICT. > > I think the f

[VOTE] Accumulo Bylaws, vote 2

Please vote on the proposed bylaws, as available at *https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup * A nicer-to-read version is available at

Re: [VOTE] Accumulo Bylaws, vote 2

Line 103 incorrectly links to the release mechanism page[1] both when it should and when it should link to the release governance page[2]. Sorry I hadn't noticed it pre-vote. Keep it in a follow on? Or start Vote 3 while Vote 2 is still in progress? [1]: http://accumulo.apache.org/releasing.html

Re: [VOTE] Apache Accumulo 1.5.1-RC3

That README was probably written without consideration of the implication for inner-classes. There is a strict interpretation, yes, but the intent is certainly not clear. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Mar 28, 2014 at 1:12 PM, Sean Busbey wrote: > The README is a

Re: [DISCUSS] MiniAccumuloCluster goals and approach

I don't think any of this should be done for 1.6.0, but I like the idea of creating a separate cluster interface for testing. I think it should be integrated into the accumulo-maven-plugin, also. I think the idea should be hammered out, and tested as a separate thing, to experiment with the options

Re: [VOTE] Accumulo Bylaws, vote 2

+1 LGTM On 3/28/14, 6:55 AM, Bill Havanki wrote: Please vote on the proposed bylaws, as available at *https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Ah, if all I need to do is change the class name to org.apache.accumulo.core.client.mapreduce.RangeInputSplit I feel kind of dumb. I didn't realize it was renamed. I can do that. On a separate note (maybe more appropriate for the user list) but keeping in here for continuity sake: We have an

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Don, If you can file a jira with some example code that covers what parts of the 1.5.0 API you hit, I can see if I can a patch to get you working. That would give you a patch you could apply on top of 1.5.1 now and when 1.5.2 comes out it would correctly support the API. -Sean On Fri, Mar 28, 2

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Also, reading back through this chain, it was state as unclear as to whether or not an inner class of a class in the public API is also, itself, in the public API. This should also be clarified in our definition of public API in the README. Obviously, Don and Sean both agree that it should be.

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Derp. I was looking right at that too and forgot that the parent class would show up in the full name. I'll make a ticket for that a while. That's easy enough to fix. On 3/28/14, 9:46 AM, Sean Busbey wrote: the class name changed 1.5.0 org.apache.accumulo.core.client.mapreduce.InputFormatBas

Re: [VOTE] Accumulo Bylaws, vote 2

In that case, +1 On Fri, Mar 28, 2014 at 11:43 AM, Billie Rinaldi wrote: > I don't think fixing broken links invalidates this vote. Just fix them and > let's keep it going. > > > On Fri, Mar 28, 2014 at 9:33 AM, Sean Busbey >wrote: > > > Line 103 incorrectly links to the release mechanism page

Re: [VOTE] Accumulo Bylaws, vote 2

+1 On Fri, Mar 28, 2014 at 6:55 AM, Bill Havanki wrote: > Please vote on the proposed bylaws, as available at > > * > https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup > < > https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext

Re: [VOTE] Accumulo Bylaws, vote 2

+1 for these bylaws (I agree with Billie that fixing the broken link shouldn't invalidate the vote). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Mar 28, 2014 at 9:55 AM, Bill Havanki wrote: > Please vote on the proposed bylaws, as available at > > *https://svn.apache.org/view

Re: [VOTE] Accumulo Bylaws, vote 2

I don't think fixing broken links invalidates this vote. Just fix them and let's keep it going. On Fri, Mar 28, 2014 at 9:33 AM, Sean Busbey wrote: > Line 103 incorrectly links to the release mechanism page[1] both when it > should and when it should link to the release governance page[2]. > >

Re: [VOTE] Apache Accumulo 1.5.1-RC3

the class name changed 1.5.0 org.apache.accumulo.core.client.mapreduce.InputFormatBase.RangeInputSplit 1.5.1 org.apache.accumulo.core.client.mapreduce.RangeInputSplit That breaks both source and binary compatibility. In this specific case, making things comaptible again isn't hard, but I want

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Be warned, TabletLocator isn't considered part of the public API and can change suddenly between releases. On Fri, Mar 28, 2014 at 10:47 AM, Keith Turner wrote: > You could use listSplits() and then tablet locator > > > http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/client/impl

Re: [VOTE] Apache Accumulo 1.5.1-RC3

Don, What *exactly* happened in your application? Changes that were made added more information inside of RangeInputSplit, as well as the class was moved to its own java file instead of being embedded inside of InputFormatBase. The package did not change -- I imagine you may have needed to re

Re: [VOTE] Apache Accumulo 1.5.1-RC3

According to the definition of the public API in version 1.5.0, RangeInputSplit is a part of the public API. On Fri, Mar 28, 2014 at 11:26 AM, Josh Elser wrote: > Devil's advocate: RangeInputSplit isn't part of the public API either, so > it comes with the same risks that TabletLocator would. >

Re: [DISCUSS] MiniAccumuloCluster goals and approach

Oh, I like that idea, Bill & Sean. Package: org.apache.accumulo.cluster Public API: org.apache.accumulo.cluster.AccumuloCluster MAC: org.apache.accumulo.cluster.mini.MiniAccumuloCluster (implements AccumuloCluster, allows for backwards compat) Yarn: org.apache.accumulo.cluster.yarn Docker: ...

Re: Accumulo site Bootstrapped

I solicited some ideas from a colleague, and he recommended maybe putting the Accumulo logo in the menu, or maybe an alternate version, without the surrounding boxes. He also recommended utilizing the scrolling nav bar (especially for long pages), as on http://getbootstrap.com/components/ It woul

Re: [DISCUSS] Reviewing design documents

On Fri, Mar 28, 2014 at 12:23 AM, Sean Busbey wrote: > Aside from the occasional stability problem, I really like the idea of > using ReviewBoard. It has the best option for in-context commenting amongst > our options at Apache AFAICT. > Another plus is that the inline discussion threads go w/ a