Re: Interesting bug report

;ke...@deenlo.com> wrote: > On Mon, Jan 25, 2016 at 10:59 AM, John Vines <vi...@apache.org> wrote: > > > Of course, it's when I hit send that I realize that we could mitigate by > > making the client aware of the master state, and if the system is shut > down > >

Re: Interesting bug report

While we want to be fault tolerant, there's a point where we want to eventually fail. I know we have a couple never ending retry loops that need to be addressed (https://issues.apache.org/jira/browse/ACCUMULO-1268), but I'm unsure if queries suffer from this problem. Unfortunately, fault

Re: Interesting bug report

Of course, it's when I hit send that I realize that we could mitigate by making the client aware of the master state, and if the system is shut down (which was the case for that ticket), then it can fail quickly with a descriptive message. On Mon, Jan 25, 2016 at 10:58 AM John Vines <

Re: [DISCUSS] Enable PreCommit build

+1 On Fri, Jan 8, 2016 at 12:58 PM Keith Turner wrote: > +1 > > On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser wrote: > > > Hi, > > > > Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to see > > what people think about turning this on by

Re: [VOTE] Accumulo 1.5.4-rc2

+1, license and notify issues resolved (agreed that ACCUMULO-4003 isn't a blocker) On Fri, Sep 18, 2015 at 1:40 PM Sean Busbey wrote: > +1 > > * checked sigs > * checked hashs > * verified src tarball matches RC tag > * verified all LICENSE and NOTICE files (hit

Re: [VOTE] Accumulo 1.5.4-rc1

-1 I'm with Sean on this one. Ignoring now known licensing issues because we hadn't handled them in the past is not a valid excuse. On Thu, Sep 10, 2015 at 2:27 PM Sean Busbey wrote: > As members of the PMC, we're required to verify all releases we approve of > meet ASF

Re: Separate Performance Tests execution documentation

README in the top of the testing module? On Tue, Jul 7, 2015 at 12:18 PM Josh Elser josh.el...@gmail.com wrote: I committed https://issues.apache.org/jira/browse/ACCUMULO-3929 yesterday. Had a thought today that it might be beneficial to write down how it works somewhere, but I don't know

Re: Start scripts and address/hostname

This may be tangential, but I heard the scripts for hadoop 3 had a massive rewrite. Perhaps they can be consulted for desired behavior? On Fri, Jun 26, 2015 at 2:03 PM Eric Newton eric.new...@gmail.com wrote: Our ops people use the start-here.sh scripts to bring services back up after

Re: 1.7 branch creation

I would attach cat pictures but the email aliases strips them off. Aside from that, sounds good. On Wed, Apr 15, 2015 at 3:22 PM Josh Elser josh.el...@gmail.com wrote: End of week? Any objections/complaints/opinions/cat-pictures? I'm thinking our branches would then look like 1.5 -

Re: Redundant code in ZKAuthorizor::initializeSecurity ?

Yup, they look like they don't belong there. On Thu, Feb 19, 2015 at 1:06 PM, Srikanth Viswanathan srikant...@gmail.com wrote: There appears to be redundant code in the ZKAuthorizor's 'initializeSecurity' method. It's initializing a bunch of permissions that are unnecessary in the authorizor.

Re: Fw: accumulo clusters

ZooKeeper should always be done in odd quantities. For such a small cluster, you may just want to dual purpose your workers as zk nodes though. I really can't say more without knowing more about the underlying hardware. On Tue, Jan 13, 2015 at 4:08 AM, panqing...@163.com panqing...@163.com wrote:

Re: accumulo master is down

This is an indicator that something is hitting that port with a different protocol. Make sure you don't have anything doing port scanning, particularly for the default ports (monitor is ). Be aware, then some pre-packaged hadoop releases do have monitoring software that may be doing this. On

Re: accumulo master is down

Another option is to change the default port in your accumulo-site.xml file (master.port.client) to a port that isn't being hit by that scan. On Tue, Jan 13, 2015 at 10:41 AM, John Vines vi...@apache.org wrote: This is an indicator that something is hitting that port with a different protocol

Re: [VOTE][LAZY] Format all supported branches

+1 On Wed, Jan 7, 2015 at 3:12 PM, Christopher ctubb...@apache.org wrote: To make it easier to apply some minimal checkstyle rules for ACCUMULO-3451, I'm announcing my intentions to do a full, one-time, auto-format and organize imports on all our supported branches (1.5, 1.6, and master) to

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

of it, into another table. How do you propose to address that? With additional permissions to ensure not just everybody can perform this action? With a check to verify that the same iterators exist on the destination table that existed on the source table? John Vines wrote: I see

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

of it, into another table. How do you propose to address that? With additional permissions to ensure not just everybody can perform this action? With a check to verify that the same iterators exist on the destination table that existed on the source table? John Vines wrote: I see

Re: Checkstyle Notes

I share sentiments with Josh. I'm all for a more universally supported standard. Going back down to 100 characters feels limiting and I'm not a fan, but I'm not going to let that stop me. On Tue, Dec 23, 2014 at 1:36 PM, Josh Elser josh.el...@gmail.com wrote: Thanks for taking the time to do

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

#file741888line84 Are the tables offline? If not, then the splits could change during this operation. They are not, but this isn't an issue. The locks prevent a merge and the bulk import code we're utilizing handles tablets splitting mid-operation. On Oct. 30, 2014, 4:06 p.m., John Vines

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

/CloneIntoIT.java PRE-CREATION Diff: https://reviews.apache.org/r/27198/diff/ Testing --- Includes CloneIntoIT, which exercises all permutations of the flags. Existing BulkIT still functions as intended for validation of no feature loss in refactoring exiting code for multi-purposing. Thanks, John

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

: https://reviews.apache.org/r/27198/diff/ Testing --- Includes CloneIntoIT, which exercises all permutations of the flags. Existing BulkIT still functions as intended for validation of no feature loss in refactoring exiting code for multi-purposing. Thanks, John Vines

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

oversights in it - John Vines On Dec. 22, 2014, 7:59 p.m., John Vines wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27198

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

, visit: https://reviews.apache.org/r/27198/#review65843 --- On Dec. 22, 2014, 7:59 p.m., John Vines wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

this operation. John Vines wrote: They are not, but this isn't an issue. The locks prevent a merge and the bulk import code we're utilizing handles tablets splitting mid-operation. kturner wrote: What about the following situation? Seems like this has the possibility

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

of it, into another table. How do you propose to address that? With additional permissions to ensure not just everybody can perform this action? With a check to verify that the same iterators exist on the destination table that existed on the source table? John Vines wrote: I see

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

of it, into another table. How do you propose to address that? With additional permissions to ensure not just everybody can perform this action? With a check to verify that the same iterators exist on the destination table that existed on the source table? John Vines wrote: I see

Re: Client on host can't connect to Accumulo in Docker instance

The ip the processes inside docker resolve to need to be resolveable from outside docker, which iirc, is not something easily achieved in Docker. On Mon, Dec 15, 2014 at 6:54 PM, David Medinets david.medin...@gmail.com wrote: Can I use the accumulo shell with the MiniAccumuloCluster? That's an

Re: Official Guidance to users regarding removal of functions

Wouldn't this be resolved with our SemVer sqwitch? On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL kep...@ll.mit.edu wrote: When we remove functions, do we have any official guidance to our users who may have built applications that use those functions? Right now, the

Re: Official Guidance to users regarding removal of functions

More likely we'd have a fully backwards compatible API for each major version. SemVer allows for it and I think that grants us enough room for growth while still securing things for future releases. On Thu, Dec 11, 2014 at 2:36 PM, Adam Fuchs afu...@apache.org wrote: Awesome -- ACCUMULO-2589

Re: [VOTE] adoption of semver

+1 On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner ke...@deenlo.com wrote: +1 On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi bil...@apache.org wrote: I would like to call a vote on adopting semantic versioning ( http://semver.org/) for future releases. This vote is subject to majority

Re: [VOTE] adoption of semver

Adam, the vote isn't for 2.0.0, it's for all future releases. Can you please clarify your vote? On Tue, Dec 9, 2014 at 3:40 PM, Adam Fuchs afu...@apache.org wrote: +1 for semver version 2.0.0 Assuming this passes, let's make sure we grab a copy for posterity and post it on our site. Adam

Re: [DISCUSS] Semantic Versioning

Just to make sure I'm understanding this before we get into another vote thread kerfluffle, if we adopt semver in 1.7.0, include a new client api in 1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not require) removing the deprecated api in 2.0.0, correct? On Mon, Dec 8, 2014

Re: [DISCUSS] Semantic Versioning

I think there's an issue with this course of discussion because we're discussion issues of our current 1.x release style while also discussion Semver, both of which are incongruent with one another. Perhaps we need to segregate adopting semver for 2.0.0 (which is waht I assumed), vs. adopting

Re: [DISCUSS] Semantic Versioning

[X]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional strictness to require documenting deprecation for at least 1 major release before possible to consider in the next major release [X]: adopt additional strictness to ensure forward compatibility between bugfix releases [ ]: start

Re: [DISCUSS] Semantic Versioning

, or -1. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Dec 5, 2014 at 1:51 PM, John Vines vi...@apache.org wrote: [X]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional strictness to require documenting deprecation for at least 1 major release before possible

Re: [VOTE] API release policy for 1.7/2.0

On Wed, Dec 3, 2014 at 4:06 PM, Josh Elser josh.el...@gmail.com wrote: Can we bring the discussion back around? I feel like we have two separate things going on here. 1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by avoiding any removal or additional deprecation. Do you

Re: [VOTE] API release policy for 1.7/2.0

On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey bus...@cloudera.com wrote: On Dec 4, 2014 6:55 AM, Josh Elser josh.el...@gmail.com wrote: (I was still confused so I just chatted with John on the subject of his -1) He was under the impression that it would not be feasible to leave the

Re: [VOTE] API release policy for 1.7/2.0

Sent from my phone, please pardon the typos and brevity. On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote: On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote: It's hard to track this down- http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has

Re: [VOTE] API release policy for 1.7/2.0

On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote: Sent from my phone, please pardon the typos and brevity. On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote: On Wed, Dec 3, 2014 at 6:48

Re: [VOTE] API release policy for 1.7/2.0

On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser josh.el...@gmail.com wrote: John Vines wrote: Though I feel the biggest reasoning is our switch to semantic versioning. And from semver.org, 1. MAJOR

Re: [VOTE] API release policy for 1.7/2.0

On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com wrote: John Vines wrote: On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com wrote: John Vines wrote: Though I feel the biggest reasoning

Re: [VOTE] API release policy for 1.7/2.0

On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 12:17 PM, John Vines vi...@apache.org wrote: On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser josh.el...@gmail.com wrote: John Vines wrote: On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke

Re: [VOTE] API release policy for 1.7/2.0

...@cloudera.com wrote: On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser josh.el...@gmail.com wrote: John Vines wrote: On Thu, Dec 4, 2014 at 11:52 AM, Keith Turnerke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 11:40 AM, Josh Elserjosh.el...@gmail.com wrote: John Vines wrote: Though

Re: [VOTE] API release policy for 1.7/2.0

ctubb...@apache.org wrote: On Thu, Dec 4, 2014 at 11:30 AM, John Vines vi...@apache.org wrote: Sent from my phone, please pardon the typos and brevity. On Dec 4, 2014 11:20 AM, Keith Turner ke...@deenlo.com wrote: On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote: It's

Re: [VOTE] API release policy for 1.7/2.0

Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0. This is not something I encourage but I think this is something we should have in our pocket just in case. On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 12:59 PM, John Vines vi

Re: [VOTE] API release policy for 1.7/2.0

:12 PM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner ke...@deenlo.com wrote: On Thu, Dec 4, 2014 at 4:00 PM, John Vines vi...@apache.org wrote: Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0. This is not something I encourage

Re: [VOTE] API release policy for 1.7/2.0

Accidentally sent to just Shawn before Sent from my phone, please pardon the typos and brevity. -- Forwarded message -- From: John Vines vi...@apache.org Date: Dec 3, 2014 10:01 AM Subject: Re: [VOTE] API release policy for 1.7/2.0 To: Sean Busbey bus...@cloudera.com Cc: Sent

Re: [VOTE] API release policy for 1.7/2.0

, Dec 2, 2014 at 6:16 PM, Christopher ctubb...@apache.org wrote: On Tue, Dec 2, 2014 at 5:18 PM, John Vines vi...@apache.org wrote: On Tue, Dec 2, 2014 at 3:14 PM, Christopher ctubb...@apache.org wrote: On Tue, Dec 2, 2014 at 3:07 PM, John Vines vi...@apache.org wrote: -1 I do not like

Re: [VOTE] API release policy for 1.7/2.0

...@deenlo.com wrote: On Wed, Dec 3, 2014 at 5:28 PM, John Vines vi...@apache.org wrote: I stand by my -1. This vote would guarantee a level of API compatibility that I don't think we should be held to. Can you give some some specific reasons for your -1? On Wed, Dec 3, 2014 at 5:15 PM

Re: [VOTE] API release policy for 1.7/2.0

...@deenlo.com wrote: On Tue, Dec 2, 2014 at 3:07 PM, John Vines vi...@apache.org wrote: -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for the 2.0 API. We have already come to the consensus that 2.0 will break the 1.x API which provides a lot of breathing room

Re: [VOTE] API release policy for 1.7/2.0

I already cited sources for it in my previous response. On Wed, Dec 3, 2014 at 6:57 PM, Christopher ctubb...@apache.org wrote: On Wed, Dec 3, 2014 at 5:28 PM, John Vines vi...@apache.org wrote: I stand by my -1. This vote would guarantee a level of API compatibility that I don't think we

Re: [VOTE] API release policy for 1.7/2.0

On Wed, Dec 3, 2014 at 7:02 PM, Christopher ctubb...@apache.org wrote: On Wed, Dec 3, 2014 at 6:48 PM, John Vines vi...@apache.org wrote: It's hard to track this down- http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has Busbey mentioning that 2.0 was breaking, which no one

Re: [VOTE] API release policy for 1.7/2.0

-1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for the 2.0 API. We have already come to the consensus that 2.0 will break the 1.x API which provides a lot of breathing room and freedom from old decisions. This causes this issue to come roaring back and an even larger

Re: [VOTE] API release policy for 1.7/2.0

On Tue, Dec 2, 2014 at 3:14 PM, Christopher ctubb...@apache.org wrote: On Tue, Dec 2, 2014 at 3:07 PM, John Vines vi...@apache.org wrote: -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for the 2.0 API. We have already come to the consensus that 2.0 will break

Re: [VOTE] ACCUMULO-3176

I was having issues with apache's mail forwarding. I would have been +1. I don't consider adding a new api breaking it. It would be nice to have the root synchronization of config updates settled, but that was outside the scope of the ticket. On Mon, Dec 1, 2014, 3:55 PM Corey Nolet

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

, visit: https://reviews.apache.org/r/27198/#review59201 --- On Oct. 29, 2014, 8:52 p.m., John Vines wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

On Oct. 30, 2014, 4:06 p.m., John Vines wrote: I have only reviewed the FATE ops so far. How will this work w/ replication? I am thinking another possible approach may be to make a clone operation that accepts multiple input tables and creates a new table. The reason I am

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

0, otherwise it returns 100. It should be called in isReady(), and isReady() should return what it returns. John Vines wrote: CloneTable does it in the call space, as a heads up then kturner wrote: Below is the src reservation in isReady() https://github.com/apache

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

in the implementation. This will help us stay closer to compatibility across versions. John Vines wrote: This isn't public api, this is only used for master-tserver. Josh Elser wrote: Ah, I didn't notice that the first time around, thanks for pointing it out. However, even

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27198/#review58795 --- On Oct. 29, 2014, 8:52 p.m., John Vines wrote

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

it. - John --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27198/#review58675 --- On Oct. 25, 2014, 7:31 p.m., John Vines wrote

Re: Review Request 27198: ACCUMULO-3236 introducing cloneInto feature

. You can keep the old bulkImport method around and just call the new addFiles method in the implementation. This will help us stay closer to compatibility across versions. John Vines wrote: This isn't public api, this is only used for master-tserver. Josh Elser wrote: Ah, I

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

to start a mini instance, stop it, use internal exec methods to start a zookeeper, and then point another mac to the old mini instance. John Vines wrote: I'm gonna be blunt - this is really really hard and I think it can be punted to a ticket for future work kturner wrote: I

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

stopping issues which seem to be related to ACCUMULO-2985 After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

to start a mini instance, stop it, use internal exec methods to start a zookeeper, and then point another mac to the old mini instance. John Vines wrote: I'm gonna be blunt - this is really really hard and I think it can be punted to a ticket for future work kturner wrote: I

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

issues which seem to be related to ACCUMULO-2985 After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

generated e-mail. To reply, visit: https://reviews.apache.org/r/23397/#review57431 --- On Oct. 20, 2014, 8:09 p.m., John Vines wrote: --- This is an automatically generated e-mail

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

trying to connection to Accumulo instance 2 John Vines wrote: So you're expecting this to work with a new zookeeper? Standard Accumulo doesn't work with a new ZK instance, why would you expect the MAC equivalent to? kturner wrote: Its just what my IT did. Although I think

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23397/#review47792 --- On July 10, 2014, 10:48 p.m., John Vines wrote: --- This is an automatically

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

://reviews.apache.org/r/23397/#review47661 --- On July 10, 2014, 10:48 p.m., John Vines wrote: --- This is an automatically generated e-mail. To reply, visit: https

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

(updated) 0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch https://reviews.apache.org/media/uploaded/files/2014/10/15/1ee9c409-65de-4a44-a86e-e905b4593a8f__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

-41e1-8495-b42d050ddc93__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

-2985 After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Accumulo-2841

Go for it! Sent from my phone, please pardon the typos and brevity. On Sep 3, 2014 4:13 PM, Jenna Huston jenna.husto...@gmail.com wrote: John Vines, would it be ok if I worked on and submitted a patch to Accumulo ticket 2841? Thanks! Jenna

Re: [DISCUSS] Removing relative paths from metadata

That is my issue with Keith. Requiring a double dot upgrade to do a single dot upgrade is a pretty big break in our operating procedure up until this point. How do we ensure people don't go to 1.7.0 straight from 1.6.1 and earlier versions? On Wed, Jul 23, 2014 at 10:03 AM, Keith Turner

Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

); System.out.println(Stopping); mac.stop(); System.out.println(Stopped); } } Which runs fine, except stopping issues which seem to be related to ACCUMULO-2985 After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

- John --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23397/#review47585 --- On July 10, 2014, 5:24 p.m., John Vines wrote

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

to ACCUMULO-2985 After running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

running this, I validated that the table was created in the real accumulo instance via zkCli Thanks, John Vines

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

On July 10, 2014, 5:50 p.m., Sean Busbey wrote: minicluster/src/main/java/org/apache/accumulo/minicluster/MiniAccumuloConfig.java, line 259 https://reviews.apache.org/r/23397/diff/1/?file=627812#file627812line259 nit: whitesapce John Vines wrote: Are these nits

Re: Review Request 23391: ACCUMULO-2986 ease use of rat plugin.

On July 10, 2014, 8:42 p.m., Christopher Tubbs wrote: -1 There's absolutely no reason to create a profile and options to skip the execution of the plugin since there is a built-in mechanism for controlling the rat check's impact on the build (eg. by setting rat.ignoreErrors). This

MiniAccumuloConfig setProperty

In using MAC on 1.6.1-SNAPSHOT, I noticed that the configimpl has a setProperty that is not exposed in the general MiniAccumuloConfig. Is this intentional or an oversight?

Re: Review Request 23397: ACCUMULO-2984 Support Running MAC against a standard instance

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23397/#review47622 --- On July 10, 2014, 6:43 p.m., John Vines wrote

Re: Make accumulo shell easy to use.

Unfortunately to run the shell, it does seem like accumulo-env.sh needs to be readable, even in the case where you have those variables set (and are using the shell's -z flag). There seems to be a hack by setting ACCUMULO_TEST env var, but that seems really hacky and rediculous. On Wed, Jun 11,

Re: [DISCUSS] Should we support upgrading 1.4 - 1.6 w/o going through 1.5?

My comfort with this is based solely on the amount of effort and complexity involved. I have no direct qualms with providing that path, on the assumption we don't spend an exorbitant amount of hours developing it and end up with a ridiculous amount of code brought up to support this which we have

Re: Review Request 21557: ACCUMULO-2766 fix wal group commit

/DfsLogger.java https://reviews.apache.org/r/21557/#comment77307 I think that before this loop the closeLock and/or closed should be checked and if it is closed, then LogClosedExceptions should be placed on all of the LogWorks, not the Exception received. - John Vines On May 16, 2014, 5:17 p.m

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

Yes, restore the old behavior On Wed, May 14, 2014 at 4:38 PM, Sean Busbey bus...@cloudera.com wrote: We don't have a formal onboarding process for drawing in new contributors, but a recent ASF Infra change impacts what I've observed historically. Here's what I've seen historically, more or

Re: [VOTE] end of life plan for 1.4 branch

+0 I want to EOL 1.4.x but I am having difficulties following this discussion. If someone could provide a tldr; I will probably change my vote. On Tue, May 6, 2014 at 12:31 PM, Ryan Leary r...@bbn.com wrote: +1 Thanks for encouraging votes from non-committers. I think having three major

Re: [VOTE] Accumulo 1.6.0-RC5

+1 verified signatures and checksums, ran tests against hadoop 1 and 2. On Tue, Apr 29, 2014 at 5:33 PM, Christopher ctubb...@apache.org wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit: 06162580e885f11863d1a6d22f952bce35b78b68 Branch:

Re: [VOTE] Accumulo Bylaws - Bylaw Change Changes

This vote passed +4 to -3 19 days ago, but was missed. I am updating the website now to make these changes. On Fri, Apr 4, 2014 at 2:41 PM, John Vines vi...@apache.org wrote: That leaves me conflicted. I have a substantial dislike for doing things a way solely because that's how they have

Re: [VOTE] Accumulo 1.6.0-RC4

Please change the subject if you're going to change this into a conversation about when to start votes. This subject is for votes for an RC candidate. On Mon, Apr 28, 2014 at 11:30 AM, William Slacum wilhelm.von.cl...@accumulo.net wrote: I was concerned about the lack of activity. I don't

Re: [VOTE] Accumulo 1.6.0-RC4

+1 On Fri, Apr 25, 2014 at 8:35 PM, Christopher ctubb...@apache.org wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit: 95ddea99e120102ce3316efbbe4948b574e59bc3 Branch: 1.6.0-RC4 Staging repo:

Re: CHANGES file for 1.6.0-RC5

+1 b +0 c On Mon, Apr 28, 2014 at 9:48 PM, Bill Havanki bhava...@clouderagovt.comwrote: b, and prefer c over d but not overly so On Mon, Apr 28, 2014 at 7:45 PM, Sean Busbey bus...@cloudera.com wrote: B and C (though I would like subtasks to be listed last) On Mon, Apr 28, 2014

Re: compatibility check between 1.5.x and 1.6.0?

+1 On Wed, Apr 23, 2014 at 10:53 AM, Josh Elser josh.el...@gmail.com wrote: On 4/23/14, 10:47 AM, Sean Busbey wrote: Okay, I think all of these incompatibilities are things that should not have been in the public API in the first place. * client.admin.SecurityOperationsImpl *

Re: [VOTE] Accumulo 1.6.0-RC3

-1 On Tue, Apr 22, 2014 at 11:49 AM, Sean Busbey bus...@cloudera.com wrote: -1 due to ACCUMULO-2713 On Mon, Apr 21, 2014 at 5:02 PM, Christopher ctubb...@apache.org wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.0. Git Commit:

Re: 551 JIRA Tickets Over 2 Years Old

, bugs, and other active features? On Apr 19, 2014 3:51 PM, John Vines vi...@apache.org wrote: Won't fix isn't accurate though. We're not saying we will reject work on them, they're just not a high priority. On Sat, Apr 19, 2014 at 3:03 PM, Christopher ctubb

Re: 551 JIRA Tickets Over 2 Years Old

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,

Re: 551 JIRA Tickets Over 2 Years Old

outstanding work. (The obvious question, then, is does it help in some way?). They can always be re-opened if we decide it's worth doing. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Sat, Apr 19, 2014 at 1:05 PM, John Vines vi...@apache.org wrote: Just because they're old doesn't

Re: [VOTE] Accumulo 1.6.0-RC2

-1 due to ACCUMULO-2700 On Thu, Apr 17, 2014 at 11:25 PM, Josh Elser josh.el...@gmail.com wrote: Just ingested 500M entries with CI and verified them successfully too. On 4/17/14, 6:59 PM, Josh Elser wrote: +1 * Built and tested (unit and integration) src tarball against Apache Hadoop

  1   2   3   4   5   >