ingest multiple times using a client with only a Kerberos identity
(no user/password provided). Used MIT Kerberos with Apache Hadoop 2.6.0 and
Apache ZooKeeper 3.4.5.
Thanks,
Josh Elser
continuous ingest multiple times using a client with only a Kerberos identity
(no user/password provided). Used MIT Kerberos with Apache Hadoop 2.6.0 and
Apache ZooKeeper 3.4.5.
Thanks,
Josh Elser
Dave, consult http://accumulo.apache.org/git.html
tl;dr No, the 1.6 branch is for the lifetime of all 1.6 versions.
WRT the other branches you are seeing, I'm guessing it's Corey doing
something in preparation for making a 1.6.2.
dlmar...@comcast.net wrote:
We have 1.6, 1.6.2-SNAPSHOT, and
Dave Marion wrote:
That didnt clear it up for me. BTW, the release management section needs to
be changed now that we have adopted semver. I will make a ticket for that.
Ok. I have already added a page stating our use of semver, so we should
also make sure whatever is unclear/inaccurate isn't
At this point, I'd be in favor of just fixing the codebase. I spend so
much time undo'ing formatting changes automatically made by Eclipse that
are unrelated to my actual changes in an attempt to keep things minimized.
Merging will be more painful (hopefully Git is smart enough for most of
Thanks for taking the time to do this. I know it can be rather monotonous.
I've read over the Google Java style guide before and liked (just about)
everything I read. The line limit of 80-100 chars *feels* limiting to me
(but I've also been told by others my senior that you very much get used
existing unit tests still function. Accumulo is functional and ran
continuous ingest multiple times using a client with only a Kerberos identity
(no user/password provided). Used MIT Kerberos with Apache Hadoop 2.6.0 and
Apache ZooKeeper 3.4.5.
Thanks,
Josh Elser
Cool stuff! Thanks for sharing. Looking forward to working with ya'll
(looking at the mention of trying to get it in as a contrib project).
Kepner, Jeremy - 0553 - MITLL wrote:
Accumulo GraphBLAS Colleagues,
As you may know, MIT is developing a native Accumulo graph mathematics
library
outside of Accumulo).
- Josh Elser
On Dec. 17, 2014, 8:31 p.m., Jenna Huston wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29176
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
On Dec. 18, 2014, 4:19 p.m., Josh Elser wrote:
core/src/main/java/org/apache/accumulo/core/file/rfile/MetricsGatherer.java,
line 36
https://reviews.apache.org/r/29176/diff/1/?file=795044#file795044line36
Why the concurrent maps? I don't see anything in these changes that
would
On Dec. 18, 2014, 4:19 p.m., Josh Elser wrote:
core/src/main/java/org/apache/accumulo/core/file/rfile/MetricsGatherer.java,
line 36
https://reviews.apache.org/r/29176/diff/1/?file=795044#file795044line36
Why the concurrent maps? I don't see anything in these changes that
would
See the methods on connector.securityOperations()
panqing...@163.com wrote:
HI,
java apihas the grant,setauths class?
--
View this message in context:
http://apache-accumulo.1065345.n5.nabble.com/java-api-grant-setauths-tp12609.html
Sent from the Developers mailing list archive at
Yes, presently that is how setauths works and there is no way to append
new authorizations to an existing set.
I'll open a ticket about introducing a '-a' option to append new
authorizations, but that will be subject to race conditions which might
be of concern.
panqing...@163.com wrote:
HI,
There is no notion of connecting to a namespace. To interact with a
namespace, just include the namespace in the table name you provide.
For example, to create a table 't' in a namespace 'n', use the table
name 'n.t'.
panqing...@163.com wrote:
HI
I created a namespace, but how should
+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
operation.
quote author='Josh Elser'
Accumulo provides an AccumuloInputFormat which allows Accumulo to be
the source of data for a MapReduce job. We also provide a few
OutputFormat implementations, the easiest to use being the
AccumuloOutputFormat which will use BatchWriters to write mutations
Accumulo provides an AccumuloInputFormat which allows Accumulo to be
the source of data for a MapReduce job. We also provide a few
OutputFormat implementations, the easiest to use being the
AccumuloOutputFormat which will use BatchWriters to write mutations
that you generate into Accumulo. You can
In essence, you're asking to apply some context classloader to a
namespace and have it propagate down to each table in that namespace as
opposed to setting it on each table? By doing so, you wouldn't have to
ensure that each table for your logical application is configured with
the same
http://accumulo.apache.org/versioning.html
Josh Elser wrote:
Working on it..
Christopher wrote:
By my tally, the vote passed with:
+1: 12
+0: 1
It looks like we can go ahead and update the relevant documentation on
the
website. Any volunteers?
--
Christopher L Tubbs II
http://gravatar.com
/src/test/java/org/apache/accumulo/test/functional/AccumuloInputFormatIT.java
fcd7afa
Diff: https://reviews.apache.org/r/29001/diff/
Testing
---
Unit tests so far. Will be running ITs before commit.
Thanks,
Josh Elser
/accumulo/server/fs/PreferredVolumeChooser.java
https://reviews.apache.org/r/28873/#comment107521
Should use StringUtils (either from Hadoop or commons-lang) instead of the
regex-based implementation on String.
- Josh Elser
On Dec. 11, 2014, 8:14 a.m., Sean Busbey wrote
You're building functions over the location of files in HDFS? Automated
configuration of instances?
Jeremy Kepner 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 official position is that
with the removal of the instance.dfs.* stuff is
important for us to handle properly.
Josh Elser wrote:
You're building functions over the location of files in HDFS? Automated
configuration of instances?
Jeremy Kepner wrote:
When we remove functions, do we have any official guidance to our
users who may
Adam Fuchs wrote:
Has anybody looked into separating the public API a bit more from the
core? It seems to me that a large number of the deprecation removal
issues are related to people failing to read section 9 of the README.
It would be great if we built an API jar that people could build
For context and as a good example of how we could be less abrasive, I'm
unexpectedly spending today updating Hive with a bunch of new reflection
because methods in 1.5 on AccumuloInputFormat no longer exist in 1.7.
setZooKeeperInstance used to take two Strings, but in 1.7 this version
of the
Great, thanks for the feedback. I just committed this in ACCUMULO-3403
Christopher wrote:
Yes, I agree you should just reintroduce the method if it was removed in
1.7, which is not yet released.
If it was removed in 1.6.{0,1}, you could also consider reintroducing it
for 1.6.2, to support those
).
server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java
https://reviews.apache.org/r/28873/#comment107315
This is going to be slow if the map is of any respectable size. Might be
better to just let it be GC'ed.
- Josh Elser
On Dec. 10, 2014, 2:58 p.m
On Dec. 10, 2014, 7:54 a.m., Christopher Tubbs wrote:
server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java,
line 44
https://reviews.apache.org/r/28873/diff/1/?file=787889#file787889line44
This is incorrect. This is not an experimental property. It
On Dec. 10, 2014, 4:26 p.m., Josh Elser wrote:
server/base/src/main/java/org/apache/accumulo/server/fs/PreferredVolumeChooser.java,
line 70
https://reviews.apache.org/r/28873/diff/2/?file=788192#file788192line70
This is going to be slow if the map is of any respectable size
of the method
those allocations will cause gc pressure during heavy splitting.
Josh Elser wrote:
bq. will cause gc pressure during heavy splitting.
*might* cause gc pressure :). I don't think you can make that assertion
without actually quantifying how much gc pressure is introduced
Look at the methods on connector.securityOperations()
panqing...@163.com wrote:
Hi
Exists in the Java API in the realization of setauths and grant command
class?
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
This sounds good. Looking forward to a vote on this. Thanks, Christopher.
Christopher wrote:
Also, I think the wording adopt semver in 1.7.0 is an incorrect way of
thinking about it. What we'd do is adopt semver for future releases, and
the master branch would be bound to those guidelines. We
/CompactCommand.java
https://reviews.apache.org/r/28739/#comment107095
This is a little confusing to me. You mean that tablets which have a single
file are compacted in addition to tablets with more than one file?
- Josh Elser
On Dec. 9, 2014, 5:32 p.m., kturner wrote
, it's good to commit
IMO.
- Josh Elser
On Dec. 9, 2014, 5:32 p.m., kturner wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28739
+1
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
Sean Busbey wrote:
On Fri, Dec 5, 2014 at 5:24 PM, Christopherctubb...@apache.org wrote:
This vote fails, with:
-1: Mike, Sean, John
+1: Christopher, Keith
Even without my implicit +1, or Bill and Josh's late -1's, the vote still
fails.
I think it would help if each person voting -1 (for
Josh Elser wrote:
Sean Busbey wrote:
On Fri, Dec 5, 2014 at 5:24 PM, Christopherctubb...@apache.org wrote:
This vote fails, with:
-1: Mike, Sean, John
+1: Christopher, Keith
Even without my implicit +1, or Bill and Josh's late -1's, the vote
still
fails.
I think it would help if each
I think he meant semver-2.0.0, not Accumulo-2.0.0.. :)
John Vines wrote:
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 Fuchsafu...@apache.org wrote:
+1 for semver version 2.0.0
Assuming this passes,
We don't provide any means to pool Connectors for you; however, you
should attempt to reuse Connectors when you can. Many libraries contain
pool implementations which you can reuse to implement this. It is fairly
common to simply pass around a Connector inside an application.
It isn't very
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
? That will greatly help with
context while reviewing them.
- Josh Elser
On Dec. 10, 2014, 6:01 a.m., Sean Busbey wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28873
On Dec. 5, 2014, 3:45 p.m., Josh Elser wrote:
shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java,
line 225
https://reviews.apache.org/r/28739/diff/1/?file=783471#file783471line225
What's the intent behind this option? Why would you ever want to
compact
Personally, I'm worried that trying to apply semver on top of 1.x as a
whole is going to lead to more problems because we don't have 3 version
bits to play with like semver expects. That was a big reason why we
were going to align semver with 2.0.0 in the first place, IIRC.
[+1]: adopt semver 2.0.0 (http://semver.org)
[+1]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[-0]:
: Josh Elser [mailto:josh.el...@gmail.com]
Sent: Saturday, December 06, 2014 1:43 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Semantic Versioning
Personally, I'm worried that trying to apply semver on top of 1.x as a whole is going to
lead to more problems because we don't have 3 version bits
-
From: Josh Elser [mailto:josh.el...@gmail.com]
Sent: Saturday, December 06, 2014 2:50 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Semantic Versioning
dlmar...@comcast.net wrote:
From what I remember in the previous discussions on this topic, there was
some confusion as to what our
and wanting to compact just those files.
Actually, I'd have the same question against, datablock size, indexblock
size, hdfs replication, and hdfs block size options too.
- Josh Elser
On Dec. 5, 2014, 4:10 a.m., kturner wrote
On Dec. 5, 2014, 3:45 p.m., Josh Elser wrote:
shell/src/main/java/org/apache/accumulo/shell/commands/CompactCommand.java,
line 225
https://reviews.apache.org/r/28739/diff/1/?file=783471#file783471line225
What's the intent behind this option? Why would you ever want to
compact
-1 Ditto, Bill; obligatory veto just because there was way too much
confusion and uncertainty. Although I generally liked what was proposed,
there's too much unrest within the rest of the community for me to +1 in
good conscience.
Bill Havanki wrote:
-1
The huge amount of discussion shows
(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
existing 1.X APIs in place with the creation of the 2.0 APIs; whereas, I
had assumed that this wouldn't be an issue.
He brought up the issue of
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.
2) In 2.0.0, what are we actually going to remove that is already deprecated
Bringing this out of the normal JIRA notification spam.
Your opinions are appreciated.
Original Message
Subject: [jira] [Commented] (ACCUMULO-1817) Use Hadoop Metrics2
Date: Wed, 3 Dec 2014 17:12:13 + (UTC)
From: Josh Elser (JIRA) j...@apache.org
Reply-To: j...@apache.org
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
existing 1.X APIs in place
I'm not trying to say that we should accept a half-baked new API, just
that, despite our best efforts, we'll likely mess up something
(interface or implementation).
We want people to use and stick to the new API (better versioning should
help us release quick fixes when we find aforementioned
John Vines wrote:
Though I feel the biggest reasoning is our switch to semantic
versioning. And from semver.org,
1. MAJOR version when you make incompatible API changes
Right and dropping deprecated APIs is an incompatible change. Do you think
the following two
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 is our switch to semantic
versioning. And from semver.org,
Sean Busbey wrote:
On Thu, Dec 4, 2014 at 11:11 AM, Josh Elserjosh.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
John Vines wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elserjosh.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
Christopher wrote:
On Wed, Dec 3, 2014 at 1:41 PM,dlmar...@comcast.net wrote:
+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases
What's the version # for the master branch if these rules are applied?
Well, I'd
Mike Drob wrote:
It looks like we've had several proposed amendments to the original
proposal, but I am very unclear on if we are voting on any of them or if
they are simply brought up as nice discussion points. There's been so
much
discussion in this VOTE thread (a strange
Sean Busbey wrote:
On Thu, Dec 4, 2014 at 11:35 AM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elserjosh.el...@gmail.com wrote:
John Vines wrote:
I feel like I'm repeating myself. My concern is that the
implementation
details of
On Dec 3, 2014 9:32 AM, Sean Busbey bus...@cloudera.com wrote:
On Tue, Dec 2, 2014 at 1:34 PM, Josh Elser josh.el...@gmail.com wrote:
Let's please try to not get snarky here, Dave. We're all trying to have
a
reasonable discussion, get to the real issues, and figure out how we can
work
I agree, I don't see a point in freezing the APIs between now and 2.0.
Although, I think slightly stronger wording could be beneficial.
I don't see any pain in adding new API methods. If the old ones are
still there, there's no potential for pain for users to keep using what
they have been.
Sean Busbey wrote:
On Wed, Dec 3, 2014 at 9:45 AM, Josh Elserels...@apache.org wrote:
And, for context, if this no-new-API freeze does stick, you would be
posthumously forcing us to go back and rip out a bunch of already committed
code for the replication feature and (possibly) the port to
Let's please try to not get snarky here, Dave. We're all trying to have
a reasonable discussion, get to the real issues, and figure out how we
can work through them without stomping on anyone. As always, you are
welcome to fork for you personal reasons -- I don't want to force you
down that
Thanks, Dave. I took his remark in the context of the original veto --
both sides have differing opinions, we have clearly hashed this out now.
I assume that Sean is still willing to work through finding something
amenable to everyone (as he would be obligated to do as long as he
considers
These read as our existing API guarantees already with the caveat to
preserve stability of any new API additions from 2.0.0 in 2.0.0 itself
and anything added [1.7.0,2.0.0) would be guaranteed until 3.0.0
Is that an accurate synopsis?
Christopher wrote:
Following the conversation on the
Christopher wrote:
On Tue, Dec 2, 2014 at 3:07 PM, John Vinesvi...@apache.org wrote:
-1 I do not like the idea of committing to1.7.0-1.9.9... API additions for
the2.0 API. We have already come to the consensus that2.0 will break the
1.x API which provides a lot of breathing room and
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
If a tl;dr helps here, Accumulo servers merge data from ZooKeeper with
the accumulo-site.xml file to determine the configuration. When a user
updates the configuration, one (or potentially zero) servers will be
aware of this change (the one who actually performed the property update).
All
Can I pick your brain some more? (also, I'm sorry if this is already
addressed in the JIRA comments somewhere. I'm being lazy)
As we know, there is a larger problem of ensuring consistent
configuration across all servers in the cluster. I don't think there is
any contention here. There are
base class
Date: Wed, 26 Nov 2014 04:25:13 + (UTC)
From: Josh Elser (JIRA) j...@apache.org
Reply-To: j...@apache.org
To: notificati...@accumulo.apache.org
[
https://issues.apache.org/jira/browse/ACCUMULO-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser
Also, I did attempt to verify that running the ITs as before (mvn
verify). File an issue if find any newly broken test.
Josh Elser wrote:
Heads up for those that might not have been following this.
I revamped how nearly all of our ITs work. In practice, it changed
relatively little
a MAC per method?
[1]:https://github.com/apache/accumulo/blob/1.6.1/test/src/test/java/org/apache/accumulo/test/functional/SimpleMacIT.java#L60
Josh Elser wrote:
Yes, this is a change. I made SharedMiniClusterIT to make ShellServerIT
run a *lot* faster, I didn't see any
On Nov. 21, 2014, 11:06 p.m., Mike Drob wrote:
core/src/main/java/org/apache/accumulo/core/client/impl/ClientContext.java,
lines 86-91
https://reviews.apache.org/r/28312/diff/1/?file=771856#file771856line86
We could make this a utility method somewhere else. I'd really rather
, Josh Elser josh.el...@gmail.com
mailto:josh.el...@gmail.com wrote:
Have we already decided to drop Hadoop 1 for 1.7.0? I can't remember
anymore.
If we haven't decided to do so already, I'd like to suggest
doing so.
- Josh
I thought
On Nov. 19, 2014, 5 p.m., Josh Elser wrote:
test/src/test/java/org/apache/accumulo/test/Accumulo3047IT.java, line 77
https://reviews.apache.org/r/28214/diff/3/?file=769778#file769778line77
This turns out to be a really common pattern that cropped up across the
test code
using annotations.
Josh Elser wrote:
Ah, I didn't take a look at that. RemoteShell was lifted from HBase,
actually (at least the general premise and some code).
Since this is internal to the user writing the test, I think I'm ok for the
time being. If this turns out to be a major pain
provide the same in
more than one place.
Thanks,
Josh Elser
+1 publish that sucker. Thanks for updating the site with the new paper.
Drew Farris wrote:
Ok, http://accumulo.staging.apache.org/papers.html is updated with a
reference to the updated paper, I'll publish tomorrow if there are no
objections..
On Sun, Nov 23, 2014 at 9:32 AM, Drew
There's some integration with Titan[1] but I've never tried it out.
Also, it looks like Giraph[2] has something.
[1] https://github.com/milindparikh/titan-accumulo
[2]
https://giraph.apache.org/apidocs/org/apache/giraph/io/accumulo/package-summary.html
fredch wrote:
Trying to use Accumulo
.
- Josh Elser
On Nov. 20, 2014, 3:27 p.m., Josh Elser wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28214/
---
(Updated
-Daccumulo.it.properties=/path/to/file.properties. Properties on the command
line will override those specified in the property if you provide the same in
more than one place.
Thanks,
Josh Elser
a MAC per method?
[1]:https://github.com/apache/accumulo/blob/1.6.1/test/src/test/java/org/apache/accumulo/test/functional/SimpleMacIT.java#L60
Josh Elser wrote:
Yes, this is a change. I made SharedMiniClusterIT to make ShellServerIT
run a *lot* faster, I didn't see any
for the configuration, but it looks strange in this call.
- Josh Elser
On Nov. 21, 2014, 4:09 a.m., Christopher Tubbs wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28312
Hi,
We've seen this happen a couple of times before. We haven't been able to
identify a likely suspect yet. What we think is happening is that a
non-Accumulo process happens to connect to an Accumulo process, send a
message that isn't a Thrift message (that Accumulo uses internally) and
it
will override those specified in the property if you provide the same in
more than one place.
Thanks,
Josh Elser
---
On Nov. 20, 2014, 3:27 p.m., Josh Elser wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28214/
---
(Updated Nov. 20, 2014, 3:27 p.m
/functional/WriteLotsIT.java
214fc2f
Diff: https://reviews.apache.org/r/28214/diff/
Testing
---
Haven't had a 100% IT pass rate yet (last run was about 95% pass rate), but I
wanted to get the code up and have some eyes on it sooner than later.
Thanks,
Josh Elser
be generally useful.
test/src/test/java/org/apache/accumulo/test/functional/SimpleMacIT.java
https://reviews.apache.org/r/28214/#comment104137
Outdated comment.
self-review...
- Josh Elser
On Nov. 19, 2014, 4:02 p.m., Josh Elser wrote
---
Haven't had a 100% IT pass rate yet (last run was about 95% pass rate), but I
wanted to get the code up and have some eyes on it sooner than later.
Thanks,
Josh Elser
later.
Thanks,
Josh Elser
the code up and have some eyes on it sooner than later.
Thanks,
Josh Elser
/java/org/apache/accumulo/test/functional/WriteLotsIT.java
214fc2f
Diff: https://reviews.apache.org/r/28214/diff/
Testing
---
Haven't had a 100% IT pass rate yet (last run was about 95% pass rate), but I
wanted to get the code up and have some eyes on it sooner than later.
Thanks,
Josh
2 major underlying component changes.
We probably should have a vote (and copy user@) just to make sure it gets
enough visibility.
Josh Elser wrote:
Have we already decided to drop Hadoop 1 for 1.7.0? I can't remember
anymore.
If we haven't decided to do so already, I'd like to suggest
, Nov 12, 2014 at 12:58 PM, Josh Elserjosh.el...@gmail.com
wrote:
Sean Busbey wrote:
On Wed, Nov 12, 2014 at 12:31 PM, Josh Elser
josh.el...@gmail.com
wrote:
Personally, I didn't really think that this contribution was in
the
spirit
of what the new codebase adoption guidelines
PM, Josh Elser josh.el...@gmail.com
wrote:
My worry with a contrib module is that, historically, code which
goes
moves to a contrib is just one step away from the grave. I think
there's
precedence for keeping them in core (as Christopher had
mentioned,
next
In test/system/bench/lib/slaves.py, change the line from lib.path
import accumulo to from lib.path import *. That fixed the error for me.
A word of warning about code-rot in these tests. I remember trying to
get them fixed up in the 1.4 time frame, and I'm not sure if they've
gotten much love
801 - 900 of 1728 matches
Mail list logo
