Emm, can it be because scalatest tries to use a different java then that specified by JAVA_HOME (which is used to compile)
On Thu, Sep 15, 2016 at 2:10 PM, Apekshit Sharma <a...@cloudera.com> wrote: > And....everything is back to red. > Because something is plaguing our builds again. :( > > If anyone knows what's problem in this case, please reply on this thread, > otherwise i'll try to fix it later sometime today. > > [INFO] *--- scalatest-maven-plugin:1.0:test (integration-test) @ hbase-spark > --- > * [36mDiscovery starting. [0m > [31m*** RUN ABORTED *** [0m > [31m java.lang.UnsupportedClassVersionError: > org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan : > Unsupported major.minor version 52.0 [0m > [31m at java.lang.ClassLoader.defineClass1(Native Method) [0m > [31m at java.lang.ClassLoader.defineClass(ClassLoader.java:803) [0m > [31m at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) [0m > [31m at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) [0m > [31m at java.net.URLClassLoader.access$100(URLClassLoader.java:71) [0m > [31m at java.net.URLClassLoader$1.run(URLClassLoader.java:361) [0m > [31m at java.net.URLClassLoader$1.run(URLClassLoader.java:355) [0m > [31m at java.security.AccessController.doPrivileged(Native Method) [0m > [31m at java.net.URLClassLoader.findClass(URLClassLoader.java:354) [0m > [31m at java.lang.ClassLoader.loadClass(ClassLoader.java:425) [0m > > > > On Mon, Sep 12, 2016 at 5:01 PM, Mikhail Antonov <olorinb...@gmail.com> > wrote: > >> Great work indeed! >> >> Agreed, occasional failed runs may not be that bad, but fairly regular >> failed runs ruin the idea of CI. Especially for released or otherwise >> supposedly stable branches. >> >> -Mikhail >> >> On Mon, Sep 12, 2016 at 4:53 PM, Sean Busbey <bus...@cloudera.com> wrote: >> >> > awesome work Appy! >> > >> > That's certainly good news to hear. >> > >> > On Mon, Sep 12, 2016 at 2:14 PM, Apekshit Sharma <a...@cloudera.com> >> > wrote: >> > > On a separate note: >> > > Trunk had 8 green runs in last 3 days! ( >> > > https://builds.apache.org/job/HBase-Trunk_matrix/) >> > > This was due to fixing just the mass failures on trunk and no change >> in >> > > flaky infra. Which made me to conclude two things: >> > > 1. Flaky infra works. >> > > 2. It relies heavily on the post-commit build's stability (which every >> > > project should anyways strive for). If the build fails >> catastrophically >> > > once in a while, we can just exclude that one run using a flag and >> > > everything will work, but if it happens frequently, then it won't work >> > > right. >> > > >> > > I have re-enabled Flaky tests job ( >> > > https://builds.apache.org/view/H-L/view/HBase/job/HBASE-Flaky-Tests/) >> > which >> > > was disabled for almost a month due to trunk being on fire. >> > > I will keep an eye on how things are going. >> > > >> > > >> > > On Mon, Sep 12, 2016 at 2:02 PM, Apekshit Sharma <a...@cloudera.com> >> > wrote: >> > > >> > >> @Sean, Mikhail: I found the alternate solution. Using user defined >> axis, >> > >> tool environment and env variable injection. >> > >> See latest diff to https://builds.apache.org/job/HBase-Trunk_matrix/ >> > job >> > >> for reference. >> > >> >> > >> >> > >> On Tue, Aug 30, 2016 at 7:39 PM, Mikhail Antonov < >> olorinb...@gmail.com> >> > >> wrote: >> > >> >> > >>> FYI, I did the same for branch-1.3 builds. I've disabled hbase-1.3 >> and >> > >>> hbase-1.3-IT jobs and instead created >> > >>> >> > >>> https://builds.apache.org/job/HBase-1.3-JDK8 and >> > >>> https://builds.apache.org/job/HBase-1.3-JDK7 >> > >>> >> > >>> This should work for now until we figure out how to move forward. >> > >>> >> > >>> Thanks, >> > >>> Mikhail >> > >>> >> > >>> On Wed, Aug 17, 2016 at 1:41 PM, Sean Busbey <bus...@cloudera.com> >> > wrote: >> > >>> >> > >>> > /me smacks forehead >> > >>> > >> > >>> > these replacement jobs, of course, also have special characters in >> > >>> > their names which then show up in the working path. >> > >>> > >> > >>> > renaming them to skip spaces and parens. >> > >>> > >> > >>> > On Wed, Aug 17, 2016 at 1:34 PM, Sean Busbey < >> sean.bus...@gmail.com> >> > >>> > wrote: >> > >>> > > FYI, it looks like essentially our entire CI suite is red, >> probably >> > >>> due >> > >>> > to >> > >>> > > parts of our codebase not tolerating spaces or other special >> > >>> characters >> > >>> > in >> > >>> > > the working directory. >> > >>> > > >> > >>> > > I've made a stop-gap non-multi-configuration set of jobs for >> > running >> > >>> unit >> > >>> > > tests for the 1.2 branch against JDK 7 and JDK 8: >> > >>> > > >> > >>> > > https://builds.apache.org/view/H-L/view/HBase/job/HBase% >> > >>> > 201.2%20(JDK%201.7)/ >> > >>> > > >> > >>> > > https://builds.apache.org/view/H-L/view/HBase/job/HBase% >> > >>> > 201.2%20(JDK%201.8)/ >> > >>> > > >> > >>> > > Due to the lack of response from infra@ I suspect our only >> options >> > >>> for >> > >>> > > continuing on ASF infra is to fix whatever part of our build >> > doesn't >> > >>> > > tolerate the new paths, or stop using multiconfiguration >> > deployments. >> > >>> I >> > >>> > am >> > >>> > > obviously less than thrilled at the idea of having several >> > multiples >> > >>> of >> > >>> > > current jobs. >> > >>> > > >> > >>> > > >> > >>> > > On Wed, Aug 10, 2016 at 6:28 PM, Sean Busbey < >> bus...@cloudera.com> >> > >>> > wrote: >> > >>> > > >> > >>> > >> Ugh. >> > >>> > >> >> > >>> > >> I sent a reply to Gav on builds@ about maybe getting names >> that >> > >>> don't >> > >>> > >> have spaces in them: >> > >>> > >> >> > >>> > >> https://lists.apache.org/thread.html/ >> > 8ac03dc62f9d6862d4f3d5eb37119c >> > >>> > >> 9c73b4059aaa3ebba52fc63bb6@%3Cbuilds.apache.org%3E >> > >>> > >> >> > >>> > >> In the mean time, is this an issue we need file with Hadoop or >> > >>> > >> something we need to fix in our own code? >> > >>> > >> >> > >>> > >> On Wed, Aug 10, 2016 at 6:04 PM, Matteo Bertozzi >> > >>> > >> <theo.berto...@gmail.com> wrote: >> > >>> > >> > There are a bunch of builds that have most of the test >> failing. >> > >>> > >> > >> > >>> > >> > Example: >> > >>> > >> > https://builds.apache.org/job/HBase-Trunk_matrix/1392/jdk= >> > >>> > >> JDK%201.7%20(latest),label=yahoo-not-h2/testReport/junit/ >> > >>> > >> org.apache.hadoop.hbase/TestLocalHBaseCluster/ >> > testLocalHBaseCluster/ >> > >>> > >> > >> > >>> > >> > from the stack trace looks like the problem is with the jdk >> name >> > >>> that >> > >>> > has >> > >>> > >> > spaces: >> > >>> > >> > the hadoop FsVolumeImpl calls setNameFormat(... + >> > >>> fileName.toString() >> > >>> > + >> > >>> > >> ...) >> > >>> > >> > and this seems to not be escaped >> > >>> > >> > so we end up with JDK%25201.7%2520(latest) in the string >> format >> > >>> and we >> > >>> > >> get >> > >>> > >> > a IllegalFormatPrecisionException: 7 >> > >>> > >> > >> > >>> > >> > 2016-08-10 22:07:46,108 WARN [DataNode: >> > >>> > >> > [[[DISK]file:/home/jenkins/jenkins-slave/workspace/HBase- >> > >>> > >> Trunk_matrix/jdk/JDK%25201.7%2520(latest)/label/yahoo-not- >> > >>> > >> h2/hbase-server/target/test-data/e7099624-ecfa-4674-87de- >> > >>> > >> a8733d13b582/dfscluster_10fdcfc3-cd1b-45be-9b5a- >> > >>> > >> 9c88f385e6f1/dfs/data/data1/, >> > >>> > >> > [DISK]file:/home/jenkins/jenkins-slave/workspace/HBase- >> > >>> > >> Trunk_matrix/jdk/JDK%25201.7%2520(latest)/label/yahoo-not- >> > >>> > >> h2/hbase-server/target/test-data/e7099624-ecfa-4674-87de- >> > >>> > >> a8733d13b582/dfscluster_10fdcfc3-cd1b-45be-9b5a- >> > >>> > >> 9c88f385e6f1/dfs/data/data2/]] >> > >>> > >> > heartbeating to localhost/127.0.0.1:34629] >> > >>> > >> > datanode.BPServiceActor(831): Unexpected exception in block >> pool >> > >>> Block >> > >>> > >> > pool <registering> (Datanode Uuid unassigned) service to >> > >>> > >> > localhost/127.0.0.1:34629 >> > >>> > >> > java.util.IllegalFormatPrecisionException: 7 >> > >>> > >> > at java.util.Formatter$FormatSpecifier.checkText( >> > >>> > >> Formatter.java:2984) >> > >>> > >> > at java.util.Formatter$FormatSpecifier.<init>( >> > >>> > >> Formatter.java:2688) >> > >>> > >> > at java.util.Formatter.parse(Formatter.java:2528) >> > >>> > >> > at java.util.Formatter.format(Formatter.java:2469) >> > >>> > >> > at java.util.Formatter.format(Formatter.java:2423) >> > >>> > >> > at java.lang.String.format(String.java:2792) >> > >>> > >> > at com.google.common.util.concurrent. >> > ThreadFactoryBuilder. >> > >>> > >> setNameFormat(ThreadFactoryBuilder.java:68) >> > >>> > >> > at org.apache.hadoop.hdfs.server. >> > datanode.fsdataset.impl. >> > >>> > >> FsVolumeImpl.initializeCacheExecutor(FsVolumeImpl.java:140) >> > >>> > >> > >> > >>> > >> > >> > >>> > >> > >> > >>> > >> > Matteo >> > >>> > >> > >> > >>> > >> > >> > >>> > >> > On Tue, Aug 9, 2016 at 9:55 AM, Stack <st...@duboce.net> >> wrote: >> > >>> > >> > >> > >>> > >> >> Good on you Sean. >> > >>> > >> >> S >> > >>> > >> >> >> > >>> > >> >> On Mon, Aug 8, 2016 at 9:43 PM, Sean Busbey < >> bus...@apache.org >> > > >> > >>> > wrote: >> > >>> > >> >> >> > >>> > >> >> > I updated all of our jobs to use the updated JDK versions >> > from >> > >>> > infra. >> > >>> > >> >> > These have spaces in the names, and those names end up in >> our >> > >>> > >> >> > workspace path, so try to keep an eye out. >> > >>> > >> >> > >> > >>> > >> >> > >> > >>> > >> >> > >> > >>> > >> >> > On Mon, Aug 8, 2016 at 10:42 AM, Sean Busbey < >> > >>> bus...@cloudera.com> >> > >>> > >> >> wrote: >> > >>> > >> >> > > running in docker is the default now. relying on the >> > default >> > >>> > docker >> > >>> > >> >> > > image that comes with Yetus means that our protoc checks >> > are >> > >>> > >> >> > > failing[1]. >> > >>> > >> >> > > >> > >>> > >> >> > > >> > >>> > >> >> > > [1]: https://issues.apache.org/jira/browse/HBASE-16373 >> > >>> > >> >> > > >> > >>> > >> >> > > On Sat, Aug 6, 2016 at 5:03 PM, Sean Busbey < >> > >>> bus...@apache.org> >> > >>> > >> wrote: >> > >>> > >> >> > >> Hi folks! >> > >>> > >> >> > >> >> > >>> > >> >> > >> this morning I merged the patch that updates us to >> Yetus >> > >>> > 0.3.0[1] >> > >>> > >> and >> > >>> > >> >> > updated the precommit job appropriately. I also changed >> it to >> > >>> use >> > >>> > one >> > >>> > >> of >> > >>> > >> >> > the Java versions post the puppet changes to asf build. >> > >>> > >> >> > >> >> > >>> > >> >> > >> The last three builds look normal (#2975 - #2977). I'm >> > gonna >> > >>> try >> > >>> > >> >> > running things in docker next. I'll email again when I >> make >> > it >> > >>> the >> > >>> > >> >> default. >> > >>> > >> >> > >> >> > >>> > >> >> > >> [1]: https://issues.apache.org/jira/browse/HBASE-15882 >> > >>> > >> >> > >> >> > >>> > >> >> > >> On 2016-06-16 10:43 (-0500), Sean Busbey < >> > bus...@apache.org> >> > >>> > >> wrote: >> > >>> > >> >> > >>> FYI, today our precommit jobs started failing because >> our >> > >>> > chosen >> > >>> > >> jdk >> > >>> > >> >> > >>> (1.7.0.79) disappeared (mentioned on HBASE-16032). >> > >>> > >> >> > >>> >> > >>> > >> >> > >>> Initially we were doing something wrong, namely >> directly >> > >>> > >> referencing >> > >>> > >> >> > >>> the jenkins build tools area without telling jenkins >> to >> > give >> > >>> > us an >> > >>> > >> >> env >> > >>> > >> >> > >>> variable that stated where the jdk is located. >> However, >> > >>> after >> > >>> > >> >> > >>> attempting to switch to the appropriate tooling >> variable >> > for >> > >>> > jdk >> > >>> > >> >> > >>> 1.7.0.79, I found that it didn't point to a place that >> > >>> worked. >> > >>> > >> >> > >>> >> > >>> > >> >> > >>> I've now updated the job to rely on the latest 1.7 >> jdk, >> > >>> which >> > >>> > is >> > >>> > >> >> > >>> currently 1.7.0.80. I don't know how often "latest" >> > updates. >> > >>> > >> >> > >>> >> > >>> > >> >> > >>> Personally, I think this is a sign that we need to >> > >>> prioritize >> > >>> > >> >> > >>> HBASE-15882 so that we can switch back to using >> Docker. I >> > >>> won't >> > >>> > >> have >> > >>> > >> >> > >>> time this week, so if anyone else does please pick up >> the >> > >>> > ticket. >> > >>> > >> >> > >>> >> > >>> > >> >> > >>> On Thu, Mar 17, 2016 at 5:19 PM, Stack < >> st...@duboce.net >> > > >> > >>> > wrote: >> > >>> > >> >> > >>> > Thanks Sean. >> > >>> > >> >> > >>> > St.Ack >> > >>> > >> >> > >>> > >> > >>> > >> >> > >>> > On Wed, Mar 16, 2016 at 12:04 PM, Sean Busbey < >> > >>> > >> bus...@cloudera.com >> > >>> > >> >> > >> > >>> > >> >> > wrote: >> > >>> > >> >> > >>> > >> > >>> > >> >> > >>> >> FYI, I updated the precommit job today to specify >> that >> > >>> only >> > >>> > >> >> compile >> > >>> > >> >> > time >> > >>> > >> >> > >>> >> checks should be done against jdks other than the >> > primary >> > >>> > jdk7 >> > >>> > >> >> > instance. >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> On Mon, Mar 7, 2016 at 8:43 PM, Sean Busbey < >> > >>> > >> bus...@cloudera.com> >> > >>> > >> >> > wrote: >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> > I tested things out, and while YETUS-297[1] is >> > present >> > >>> the >> > >>> > >> >> > default runs >> > >>> > >> >> > >>> >> > all plugins that can do multiple jdks against >> those >> > >>> > available >> > >>> > >> >> > (jdk7 and >> > >>> > >> >> > >>> >> > jdk8 in our case). >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> > We can configure things to only do a single run >> of >> > unit >> > >>> > >> tests. >> > >>> > >> >> > They'll be >> > >>> > >> >> > >>> >> > against jdk7, since that is our default jdk. That >> > fine >> > >>> by >> > >>> > >> >> > everyone? It'll >> > >>> > >> >> > >>> >> > save ~1.5 hours on any build that hits >> hbase-server. >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> > On Mon, Mar 7, 2016 at 1:22 PM, Stack < >> > >>> st...@duboce.net> >> > >>> > >> wrote: >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> >> Hurray! >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> >> It looks like YETUS-96 is in there and we are >> only >> > >>> > running >> > >>> > >> on >> > >>> > >> >> > jdk build >> > >>> > >> >> > >>> >> >> now, the default (but testing compile against >> > >>> both).... >> > >>> > Will >> > >>> > >> >> > keep an >> > >>> > >> >> > >>> >> eye. >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> >> St.Ack >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> >> On Mon, Mar 7, 2016 at 10:27 AM, Sean Busbey < >> > >>> > >> >> > bus...@cloudera.com> >> > >>> > >> >> > >>> >> wrote: >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> >> > FYI, I've just updated our precommit jobs to >> use >> > the >> > >>> > 0.2.0 >> > >>> > >> >> > release of >> > >>> > >> >> > >>> >> >> Yetus >> > >>> > >> >> > >>> >> >> > that came out today. >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > After keeping an eye out for strangeness today >> > I'll >> > >>> > turn >> > >>> > >> >> > docker mode >> > >>> > >> >> > >>> >> >> back >> > >>> > >> >> > >>> >> >> > on by default tonight. >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > On Wed, Jan 13, 2016 at 10:14 AM, Sean Busbey >> < >> > >>> > >> >> > bus...@apache.org> >> > >>> > >> >> > >>> >> >> wrote: >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > > FYI, I added a new parameter to the >> precommit >> > job: >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > > * USE_YETUS_PRERELEASE - causes us to use >> the >> > >>> HEAD of >> > >>> > >> the >> > >>> > >> >> > >>> >> apache/yetus >> > >>> > >> >> > >>> >> >> > > repo rather than our chosen release >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > > It defaults to inactive, but can be used in >> > >>> > >> >> > manually-triggered runs >> > >>> > >> >> > >>> >> to >> > >>> > >> >> > >>> >> >> > > test a solution to a problem in the yetus >> > >>> library. At >> > >>> > >> the >> > >>> > >> >> > moment, >> > >>> > >> >> > >>> >> I'm >> > >>> > >> >> > >>> >> >> > > using it to test a solution to default >> module >> > >>> > ordering >> > >>> > >> as >> > >>> > >> >> > seen in >> > >>> > >> >> > >>> >> >> > > HBASE-15075. >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > > On Fri, Jan 8, 2016 at 7:58 AM, Sean Busbey >> < >> > >>> > >> >> > bus...@cloudera.com> >> > >>> > >> >> > >>> >> >> wrote: >> > >>> > >> >> > >>> >> >> > > > FYI, I just pushed HBASE-13525 (switch to >> > Apache >> > >>> > Yetus >> > >>> > >> >> for >> > >>> > >> >> > >>> >> precommit >> > >>> > >> >> > >>> >> >> > > tests) >> > >>> > >> >> > >>> >> >> > > > and updated our jenkins precommit build to >> > use >> > >>> it. >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > Jenkins job has some explanation: >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> https://builds.apache.org/ >> > view/PreCommit%20Builds/job/ >> > >>> > >> >> > PreCommit-HBASE-Build/ >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > Release note from HBASE-13525 does as >> well. >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > The old job will stick around here for a >> > couple >> > >>> of >> > >>> > >> weeks, >> > >>> > >> >> > in case >> > >>> > >> >> > >>> >> we >> > >>> > >> >> > >>> >> >> > need >> > >>> > >> >> > >>> >> >> > > > to refer back to it: >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> https://builds.apache.org/ >> > view/PreCommit%20Builds/job/ >> > >>> > >> >> > PreCommit-HBASE-Build-deprecated/ >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > If something looks awry, please drop a >> note >> > on >> > >>> > >> >> HBASE-13525 >> > >>> > >> >> > while >> > >>> > >> >> > >>> >> it >> > >>> > >> >> > >>> >> >> > > remains >> > >>> > >> >> > >>> >> >> > > > open (and make a new issue after). >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > On Wed, Dec 2, 2015 at 3:22 PM, Stack < >> > >>> > >> st...@duboce.net> >> > >>> > >> >> > wrote: >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > >> As part of my continuing advocacy of >> > >>> > >> builds.apache.org >> > >>> > >> >> > and that >> > >>> > >> >> > >>> >> >> their >> > >>> > >> >> > >>> >> >> > > >> results are now worthy of our trust and >> > >>> nurture, >> > >>> > here >> > >>> > >> >> are >> > >>> > >> >> > some >> > >>> > >> >> > >>> >> >> > > highlights >> > >>> > >> >> > >>> >> >> > > >> from the last few days of builds: >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> + hadoopqa is now finding zombies before >> the >> > >>> > patch is >> > >>> > >> >> > committed. >> > >>> > >> >> > >>> >> >> > > >> HBASE-14888 showed "-1 core tests. The >> patch >> > >>> > failed >> > >>> > >> >> these >> > >>> > >> >> > unit >> > >>> > >> >> > >>> >> >> tests:" >> > >>> > >> >> > >>> >> >> > > but >> > >>> > >> >> > >>> >> >> > > >> didn't have any failed tests listed (I'm >> > >>> trying to >> > >>> > >> see >> > >>> > >> >> if >> > >>> > >> >> > I can >> > >>> > >> >> > >>> >> do >> > >>> > >> >> > >>> >> >> > > anything >> > >>> > >> >> > >>> >> >> > > >> about this...). Running our little >> > >>> > >> >> > >>> >> ./dev-tools/findHangingTests.py >> > >>> > >> >> > >>> >> >> > > against >> > >>> > >> >> > >>> >> >> > > >> the consoleText, it showed a hanging >> test. >> > >>> Running >> > >>> > >> >> > locally, I see >> > >>> > >> >> > >>> >> >> same >> > >>> > >> >> > >>> >> >> > > >> hang. This is before the patch landed. >> > >>> > >> >> > >>> >> >> > > >> + Our branch runs are now near totally >> > zombie >> > >>> and >> > >>> > >> flakey >> > >>> > >> >> > free -- >> > >>> > >> >> > >>> >> >> still >> > >>> > >> >> > >>> >> >> > > some >> > >>> > >> >> > >>> >> >> > > >> work to do -- but a recent patch that >> seemed >> > >>> > harmless >> > >>> > >> >> was >> > >>> > >> >> > >>> >> causing a >> > >>> > >> >> > >>> >> >> > > >> reliable flake fail in the backport to >> > >>> branch-1* >> > >>> > >> >> > confirmed by >> > >>> > >> >> > >>> >> local >> > >>> > >> >> > >>> >> >> > > runs. >> > >>> > >> >> > >>> >> >> > > >> The flakeyness was plain to see up in >> > >>> > >> builds.apache.org >> > >>> > >> >> . >> > >>> > >> >> > >>> >> >> > > >> + In the last few days I've committed a >> > patch >> > >>> that >> > >>> > >> >> > included >> > >>> > >> >> > >>> >> javadoc >> > >>> > >> >> > >>> >> >> > > >> warnings even though hadoopqa said the >> patch >> > >>> > >> introduced >> > >>> > >> >> > javadoc >> > >>> > >> >> > >>> >> >> issues >> > >>> > >> >> > >>> >> >> > > (I >> > >>> > >> >> > >>> >> >> > > >> missed it). This messed up life for folks >> > >>> > >> subsequently >> > >>> > >> >> as >> > >>> > >> >> > their >> > >>> > >> >> > >>> >> >> > patches >> > >>> > >> >> > >>> >> >> > > now >> > >>> > >> >> > >>> >> >> > > >> reported javadoc issues.... >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> In short, I suggest that >> builds.apache.org >> > is >> > >>> > worth >> > >>> > >> >> > keeping an >> > >>> > >> >> > >>> >> eye >> > >>> > >> >> > >>> >> >> > on, >> > >>> > >> >> > >>> >> >> > > >> make >> > >>> > >> >> > >>> >> >> > > >> sure you get a clean build out of >> hadoopqa >> > >>> before >> > >>> > >> >> > committing >> > >>> > >> >> > >>> >> >> anything, >> > >>> > >> >> > >>> >> >> > > and >> > >>> > >> >> > >>> >> >> > > >> lets all work together to try and keep >> our >> > >>> builds >> > >>> > >> blue: >> > >>> > >> >> > it'll >> > >>> > >> >> > >>> >> save >> > >>> > >> >> > >>> >> >> us >> > >>> > >> >> > >>> >> >> > > all >> > >>> > >> >> > >>> >> >> > > >> work in the long run. >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> St.Ack >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> On Tue, Nov 4, 2014 at 9:38 AM, Stack < >> > >>> > >> st...@duboce.net >> > >>> > >> >> > >> > >>> > >> >> > wrote: >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > >> > Branch-1 and master have stabilized and >> > now >> > >>> run >> > >>> > >> mostly >> > >>> > >> >> > blue >> > >>> > >> >> > >>> >> >> (give or >> > >>> > >> >> > >>> >> >> > > take >> > >>> > >> >> > >>> >> >> > > >> > the odd failure) [1][2]. Having a >> mostly >> > blue >> > >>> > >> branch-1 >> > >>> > >> >> > has >> > >>> > >> >> > >>> >> >> helped us >> > >>> > >> >> > >>> >> >> > > >> > identify at least one destabilizing >> > commit in >> > >>> > the >> > >>> > >> last >> > >>> > >> >> > few >> > >>> > >> >> > >>> >> days, >> > >>> > >> >> > >>> >> >> > maybe >> > >>> > >> >> > >>> >> >> > > >> two; >> > >>> > >> >> > >>> >> >> > > >> > this is as it should be (smile). >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> > Lets keep our builds blue. If you >> commit a >> > >>> > patch, >> > >>> > >> make >> > >>> > >> >> > sure >> > >>> > >> >> > >>> >> >> > subsequent >> > >>> > >> >> > >>> >> >> > > >> > builds stay blue. You can subscribe to >> > >>> > >> >> > bui...@hbase.apache.org >> > >>> > >> >> > >>> >> >> to >> > >>> > >> >> > >>> >> >> > get >> > >>> > >> >> > >>> >> >> > > >> > notice of failures if not already >> > subscribed. >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> > Thanks, >> > >>> > >> >> > >>> >> >> > > >> > St.Ack >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> > 1. >> > >>> > >> >> > >>> >> https://builds.apache.org/ >> > view/H-L/view/HBase/job/HBase- >> > >>> > 1.0/ >> > >>> > >> >> > >>> >> >> > > >> > 2. >> > >>> > >> >> > >>> >> >> https://builds.apache.org/view >> > >>> /H-L/view/HBase/job/HBase- >> > >>> > >> TRUNK/ >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> > On Mon, Oct 13, 2014 at 4:41 PM, Stack >> < >> > >>> > >> >> > st...@duboce.net> >> > >>> > >> >> > >>> >> wrote: >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> >> A few notes on testing. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> Too long to read, infra is more >> capable >> > now >> > >>> and >> > >>> > >> after >> > >>> > >> >> > some >> > >>> > >> >> > >>> >> >> work, we >> > >>> > >> >> > >>> >> >> > > are >> > >>> > >> >> > >>> >> >> > > >> >> seeing branch-1 and trunk mostly >> running >> > >>> blue. >> > >>> > >> Lets >> > >>> > >> >> > try and >> > >>> > >> >> > >>> >> >> keep it >> > >>> > >> >> > >>> >> >> > > this >> > >>> > >> >> > >>> >> >> > > >> >> way going forward. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> Apache Infra has new, more capable >> > hardware. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> A recent spurt of test fixing combined >> > with >> > >>> > more >> > >>> > >> >> > capable >> > >>> > >> >> > >>> >> >> hardware >> > >>> > >> >> > >>> >> >> > > seems >> > >>> > >> >> > >>> >> >> > > >> >> to have gotten us to a new place; >> tests >> > are >> > >>> > mostly >> > >>> > >> >> > passing now >> > >>> > >> >> > >>> >> >> on >> > >>> > >> >> > >>> >> >> > > >> branch-1 >> > >>> > >> >> > >>> >> >> > > >> >> and master. Lets try and keep it this >> > way >> > >>> and >> > >>> > >> start >> > >>> > >> >> > to trust >> > >>> > >> >> > >>> >> >> our >> > >>> > >> >> > >>> >> >> > > test >> > >>> > >> >> > >>> >> >> > > >> runs >> > >>> > >> >> > >>> >> >> > > >> >> again. Just a few flakies remain. >> Lets >> > try >> > >>> > and >> > >>> > >> nail >> > >>> > >> >> > them. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> Our tests now run in parallel with >> other >> > >>> test >> > >>> > >> suites >> > >>> > >> >> > where >> > >>> > >> >> > >>> >> >> previous >> > >>> > >> >> > >>> >> >> > > we >> > >>> > >> >> > >>> >> >> > > >> >> ran alone. You can see this sometimes >> > when >> > >>> our >> > >>> > >> zombie >> > >>> > >> >> > detector >> > >>> > >> >> > >>> >> >> > > reports >> > >>> > >> >> > >>> >> >> > > >> >> tests from another project altogether >> as >> > >>> > lingerers >> > >>> > >> >> (To >> > >>> > >> >> > be >> > >>> > >> >> > >>> >> >> fixed). >> > >>> > >> >> > >>> >> >> > > Some >> > >>> > >> >> > >>> >> >> > > >> of >> > >>> > >> >> > >>> >> >> > > >> >> our tests are failing because a >> > concurrent >> > >>> > hbase >> > >>> > >> run >> > >>> > >> >> is >> > >>> > >> >> > >>> >> undoing >> > >>> > >> >> > >>> >> >> > > classes >> > >>> > >> >> > >>> >> >> > > >> and >> > >>> > >> >> > >>> >> >> > > >> >> data from under it. Also, lets fix. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> Our tests are brittle. It takes >> 75minutes >> > >>> for >> > >>> > >> them to >> > >>> > >> >> > >>> >> complete. >> > >>> > >> >> > >>> >> >> > Many >> > >>> > >> >> > >>> >> >> > > >> are >> > >>> > >> >> > >>> >> >> > > >> >> heavy-duty integration tests starting >> up >> > >>> > multiple >> > >>> > >> >> > clusters and >> > >>> > >> >> > >>> >> >> > > mapreduce >> > >>> > >> >> > >>> >> >> > > >> >> all in the one JVM. It is a miracle >> they >> > >>> pass >> > >>> > at >> > >>> > >> all. >> > >>> > >> >> > Usually >> > >>> > >> >> > >>> >> >> > > >> integration >> > >>> > >> >> > >>> >> >> > > >> >> tests have been cast as unit tests >> > because >> > >>> > there >> > >>> > >> was >> > >>> > >> >> > no where >> > >>> > >> >> > >>> >> >> else >> > >>> > >> >> > >>> >> >> > > for >> > >>> > >> >> > >>> >> >> > > >> them >> > >>> > >> >> > >>> >> >> > > >> >> to get an airing. We have the >> hbase-it >> > >>> suite >> > >>> > now >> > >>> > >> >> > which would >> > >>> > >> >> > >>> >> >> be a >> > >>> > >> >> > >>> >> >> > > more >> > >>> > >> >> > >>> >> >> > > >> apt >> > >>> > >> >> > >>> >> >> > > >> >> place but until these are run on a >> > regular >> > >>> > basis >> > >>> > >> in >> > >>> > >> >> > public for >> > >>> > >> >> > >>> >> >> all >> > >>> > >> >> > >>> >> >> > to >> > >>> > >> >> > >>> >> >> > > >> see, >> > >>> > >> >> > >>> >> >> > > >> >> the fat integration tests disguised as >> > unit >> > >>> > tests >> > >>> > >> >> will >> > >>> > >> >> > remain. >> > >>> > >> >> > >>> >> >> A >> > >>> > >> >> > >>> >> >> > > >> review of >> > >>> > >> >> > >>> >> >> > > >> >> our current unit tests weeding the old >> > cruft >> > >>> > and >> > >>> > >> the >> > >>> > >> >> > no longer >> > >>> > >> >> > >>> >> >> > > relevant >> > >>> > >> >> > >>> >> >> > > >> or >> > >>> > >> >> > >>> >> >> > > >> >> duplicates would be a nice >> undertaking if >> > >>> > someone >> > >>> > >> is >> > >>> > >> >> > looking >> > >>> > >> >> > >>> >> to >> > >>> > >> >> > >>> >> >> > > >> contribute. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> Alex Newman has been working on making >> > our >> > >>> > tests >> > >>> > >> work >> > >>> > >> >> > up on >> > >>> > >> >> > >>> >> >> travis >> > >>> > >> >> > >>> >> >> > > and >> > >>> > >> >> > >>> >> >> > > >> >> circle-ci. That'll be sweet when it >> goes >> > >>> > >> end-to-end. >> > >>> > >> >> > He also >> > >>> > >> >> > >>> >> >> > added >> > >>> > >> >> > >>> >> >> > > in >> > >>> > >> >> > >>> >> >> > > >> >> some "type" categorizations -- client, >> > >>> filter, >> > >>> > >> >> > mapreduce -- >> > >>> > >> >> > >>> >> >> > alongside >> > >>> > >> >> > >>> >> >> > > >> our >> > >>> > >> >> > >>> >> >> > > >> >> old "sizing" categorizations of >> > >>> > >> small/medium/large. >> > >>> > >> >> > His >> > >>> > >> >> > >>> >> >> thinking >> > >>> > >> >> > >>> >> >> > is >> > >>> > >> >> > >>> >> >> > > >> that >> > >>> > >> >> > >>> >> >> > > >> >> we can run these categorizations in >> > parallel >> > >>> > so we >> > >>> > >> >> > could run >> > >>> > >> >> > >>> >> the >> > >>> > >> >> > >>> >> >> > > total >> > >>> > >> >> > >>> >> >> > > >> >> suite in about the time of the longest >> > test, >> > >>> > say >> > >>> > >> >> > 20-30minutes? >> > >>> > >> >> > >>> >> >> We >> > >>> > >> >> > >>> >> >> > > could >> > >>> > >> >> > >>> >> >> > > >> >> even change Apache to run them this >> way. >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> FYI, >> > >>> > >> >> > >>> >> >> > > >> >> St.Ack >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> >> >> > >>> > >> >> > >>> >> >> > > >> > >> > >>> > >> >> > >>> >> >> > > >> >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > >> > >>> > >> >> > >>> >> >> > > > -- >> > >>> > >> >> > >>> >> >> > > > Sean >> > >>> > >> >> > >>> >> >> > > >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> > -- >> > >>> > >> >> > >>> >> >> > busbey >> > >>> > >> >> > >>> >> >> > >> > >>> > >> >> > >>> >> >> >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> > -- >> > >>> > >> >> > >>> >> > busbey >> > >>> > >> >> > >>> >> > >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> -- >> > >>> > >> >> > >>> >> busbey >> > >>> > >> >> > >>> >> >> > >>> > >> >> > >>> >> > >>> > >> >> > > >> > >>> > >> >> > > >> > >>> > >> >> > > >> > >>> > >> >> > > -- >> > >>> > >> >> > > busbey >> > >>> > >> >> > >> > >>> > >> >> >> > >>> > >> >> > >>> > >> >> > >>> > >> >> > >>> > >> -- >> > >>> > >> busbey >> > >>> > >> >> > >>> > > >> > >>> > > >> > >>> > > >> > >>> > > -- >> > >>> > > Sean >> > >>> > >> > >>> > >> > >>> > >> > >>> > -- >> > >>> > busbey >> > >>> > >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> Thanks, >> > >>> Michael Antonov >> > >>> >> > >> >> > >> >> > >> >> > >> -- >> > >> >> > >> -- Appy >> > >> >> > > >> > > >> > > >> > > -- >> > > >> > > -- Appy >> > >> > >> > >> > -- >> > busbey >> > >> >> >> >> -- >> Thanks, >> Michael Antonov >> > > > > -- > > -- Appy > -- -- Appy
