call arn's test a little bit. ignore errors in stdout for now
show nodes when too many in the cloud status
was timing out. Don't need the test.
PUB-837: Port over the fix applied to h2o-dev, was triggering assertion error in RPC.
Merge branch 'master' of https://github.com/0xdata/h2o
looks good (no error in log) now
Fix bug introduced in e4fb84a that led to broken h2o.performance tests.
Merge branch 'master' of https://github.com/0xdata/h2o
make the ddply case single jvm, so it doesn't fail
timeout adjustment in the 2nd case
Merge branch 'master' of github.com:0xdata/h2o
max max_iter larger
also, don't use alpha = 0.8 or so any more. seems too strong
keep it down around 0.4/0.5
allow a larger error delta in the rf error result
make flatfile name have pid unique like cloud name
timeouts on a busy machine
make the R hdfs tests run again. They still go to the cdh3 cluster on 176

details:

I rebuilt the cdh3 cluster on 172-177. We always had the latest cm4 (cloudera manager 4) on our cdh3. Problem ocurred when updating all systems to the 12.04 LTS HWE stack which is the 3.11 kernel. Consistency everywhere for maintenance issues (for instance docker evidently doesn't support <3.8). Also: updates were no l
onger being released for the 3.2.x based stack.

Apparently cm4 doesn't work on the 3.11 kernel, apparently some different schema
 passing the heartbeat for the nodes. So I rolled back to the normal 12.04 LTS 3
.2.x stack on 174-177 (which are the nodes for the cdh3 cluster now)

All other systems were updated last week to 12.04 LTS HWE (3.11.x kernel).
(this is the same kernel as the Ubuntu Trusty release)

171 was not rebooted, so it has the pending update. If 171 is rebooted and somet
hing doesn't work, let me know. Things have been fine everywhere (cdh5 and hdp2.1 seem fine. I just checked win8.1_x64 on virtualbox and that's fine too. Samba seems fine.

No plans to update to 14.04 LTS.
ease enter the commit message for your changes. Lines starting
get rid of unnecessary base_port= in the build_cloud()
print extra info if any needed process kill on h2o is done and we get an exception (that we always ignored) ..also increase the timeout where we wait for the pkill to complete, and print a message if we hit the timeout (we always did, and still do, nothing if that happens. Maybe in loaded systems, the pkill (if necessary) takes a while to complete. (thinking of our low rate port busy issues). the wait timeout used to be 0.5 secs. now 2 secs. (per kill). ..the kill is only done if the process is still alive after sending an h2o shutdown, and only for local jvms (not remote host h2os..the channel shutdown is sufficient there)
some pretty printing
GLM2 fix: fixed racy assert.
get rid of unnecessary base_port overrides by test. While useful, it may be hiding port reuse issues after h2o completes (long series of tests in jenkins)
I think it proliferated due to test copying...but maybe was a hack to avoid port reuse problems in a list of tests. Should work.