All other artifacts were generated using src/assemble/build.sh Testing performed:
All unit and functional tests passed using the hadoop 1 and 2 profiles. All functional tests passed using hadoop cdh3u6 (hadoop 1 branch) All functional tests passed using hadoop cdh4.5.0 (hadoop 2 branch) 2x 24-hr CI test + verification passed (hadoop 1 and 2) 1x 36-hr CI test + verification with agitation passed (hadoop 2) 1x 72-hr CI test with agitation completed (hadoop 2) 2x 24-hr RW tests were run without agitation. 1x 24-hr RW test was run with agitation.
This vote will remain open for 72 hours (Until 2030 UTC, 27 Mar)
[ ] +1 - I have verified and accept these artifacts as the 1.4.5 release of Apache Accumulo. [ ] +0 [ ] -1 - I do not accept these artifacts as the 1.4.5 release of Apache Accumulo because... Thanks, Mike
Point of clarification, is "hadoop 1" synonymous with cdh3u6 and "hadoop 2" cdh4.5.0 for all of these tests or just the functional tests? No testing was done against Apache Hadoop/ZooKeeper artifacts yet?
-1, src/core/src/test/java/org/apache/accumulo/core/client/IteratorSettingTest.java has no license. Probably couldn't hurt for src/server/src/test/resources/log4j.properties to have a license too. On Mon, Mar 24, 2014 at 1:35 PM, Mike Drob <[EMAIL PROTECTED]> wrote:
Overall -1 for the license issue Billie mentioned, the incorrect CHANGES, and the functional test failures against Apache Hadoop 2.
I also had functional test failures with Hadoop 2 regarding MapReduce -- is JobContext still an interface in cdh4 whereas it's a class in Apache? I would assume that 1.4 should be passing against Apache 1 and 2 versions, same as we would with 1.5 and 1.6?
Summary of what I've done:
- Successfully built src tarball.
- CHANGES file is incorrect. It contains fixes that were not done (2520, 2523, 2500). Also, I don't think the Wikisearch related tickets should be included in CHANGES as they don't involve any code change inside of Accumulo 1.4.5
- Using a tarball built by the src bundle, on Centos6.5 with OpenJDK7, I installed, built native maps, started, wrote some data, stopped with an early Hadoop 2.4 build and ZooKeeper 3.4.5
- MD5 checksums are weird (generated via GPG according to Mike). They're not in the format I'm used to seeing:
I'm used to: fae2ac91eb3553f71720d27370a992b8 accumulo-1.4.5-dist.tar.gz Provided: accumulo-1.4.5-dist.tar.gz: FA E2 AC 91 EB 35 53 F7 17 20 D2 73 70 A9 92 B8
- For future RCs, it would nice to provide a single file with checksums that can be passed directly to `md5sum -c` and `sha1sum -c`. Also, no SHA1 sums?
- GPG sigs look good.
- Verified bin tarball contains native libs. Started/stopped with same hadoop/zookeeper versions previously stated.
- Had to update auto-tests to match the same example general.classpaths so they'd find Hadoop jars more reliably. Looks like some tests still don't pass with Hadoop2 (simple.examples.Examples fails about JobContext being a class instead of an interface). simple.mapreduce.MapReduceTest appears to have failed too.
- simple.shell.ShellTest also failed on the initial run, but successfully passed when re-run. simple.merge.MergeTest appears to fail consistently, I'll file a ticket for both.
1.4.5 still requires building with the different Hadoop profiles if you want Hadoop 2 to work.
So tests on Hadoop 2 mapreduce, including CDH4, will fail given artifacts made with the default profile or the Hadoop 1 profile. (As an aside, this is why I asked which profile built the binaries.) On Mar 26, 2014 8:25 PM, "Josh Elser" <[EMAIL PROTECTED]> wrote:
Oh.. really? That's kind of crappy -- we don't have that precedent anywhere else, and, tbh, I think having a single artifact makes a much better product overall (dealing with maven classifiers is horrid, not to mention the "which tarball do I use?" problem).
Is this just something extra reflection that would need to be backported from upstream to make the recompilation unnecessary?
It was gone over back when we discussed what level of Hadoop 2 support would be useful in the 1.4.x line.
Since 1.4.x is on last legs, Hadoop 1 is the primary platform for it, and the motivation for adding support is to ease upgrade matrices so more folks would be likely to get off of 1.4, consensus was that needing a special build would be sufficient.
The "what to use" is simple and covered in our README: you use our defaults if you are on Hadoop 1 and just maintaining your Accumulo. If you need Hadoop 2 you should upgrade. If you can't or don't want to upgrade Accumulo first, there is special case handling to make 1.4 work on it.
The reflection stuff to obviate having an special build went into 1.5 in a hurry between RCs. Frankly, I think including it would introduce unnecessary risk to the stability of the 1.4 line for marginal benefit.
As is, ease of single artifacts is a good reason to upgrade to 1.5+. On Mar 26, 2014 8:40 PM, "Josh Elser" <[EMAIL PROTECTED]> wrote:
On Mar 26, 2014 8:48 PM, "Mike Drob" <[EMAIL PROTECTED]> wrote: be
I would like feedback from Christopher and Bill S. on this and what we're going to do about making a Wikisearch artifact to accompany the release.
As a part of including the removal of the Wikisearch code into the contrib repo under 1.4 Christopher and I agreed that user expectations about it being available specific to the 1.4 release would be maintained.
I was under the impression that a functioning Wikisearch was a requirement for 1.4.5, as it would be consistent with all previous 1.4.x releases. On Wed, Mar 26, 2014 at 11:35 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
One thing we could do is wait until somebody requests a release of a 1.4.5 compatible Wikisearch to bother. I'm not a fan of this option, because of the change in user expectations we've previously discussed. However, I haven't been putting any time or thought into 1.4.x to have any better ideas.
The CHANGES file should, at the very least, reflect the change in the packaging to drop the wikisearch example, whether or not it is provided separately.
Apache Lucene, Apache Solr and all other Apache Software Foundation projects and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext