accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Hadoop 2.0 Support for Accumulo 1.4 Branch
Date Mon, 14 Oct 2013 16:55:51 GMT
Hey All,

I'd like to restart the conversation from end July / start August about
Hadoop 2 support on the 1.4 branch.

Specifically, I'd like to get some requirements ironed out so I can file
one or more jiras. I'd also like to get a plan for application.


Here's the requirements I have from the last thread:

1)  Maintain existing 1.4 compatibility

The only thing I see listed in the pom is Apache release (1.4.4

I don't see anything in the README[2] nor the user manual[3] on other
versions being supported.

2) Gain Hadoop 2 support

At the moment, I'm presuming this means Apache release 2.0.4-alpha since
that's what 1.5.0 builds against for Hadoop 2.

3) Test for correctness on given versions, with >= 5 node cluster

* Unit Tests
* Functional Tests
* 24hr continuous + verification
* 24hr continuous + verification + agitation
* 24hr random walk
* 24hr random walk + agitation

Keith mentioned running these against a CDH4 cluster, but I presume that
since Apache Releases are our stated compatibilities it would actually be
against whatever versions we list. Based on #1 and #2 above, I would expect
that to be Apache Hadoop and Apache Hadoop 2.0.4-alpha.

4) Binary packaging
4a) Either source produces a single binary for all accepted versions


4b) Instructions for building from source for each versions and somehow
flag what (if any) convenience binaries are made for the release.


There will be many back-ported patches. Not much active development happens
on 1.4.x now, but I presume this should still all go onto a feature branch?

Is the community preference that eventually all the changes become a single
commit (or one-per-subtask if there are multiple jiras) on the active 1.4
development branch, or that the original patches remain broken out?

For what it's worth, I'd recommend keeping them broken out. (And that's how
the initial development against CDH4 has been done.)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message