hardwire the schemas on these, for both the import_only they do to count the number of imported keys, and the 'real work' import_parse that does import again and parse (but doesn't return the number of imported keys, it returns the parseResult h2o response). Means the tests won't run at 0xdata, but that's implied by the s3 and s3n in their name
it's probably good practice for me to put the schema='local' in as a param to the import_parse() here, rather than relying on it defaulting to local, just because it's a good visual reminder of what's going on, and nice for grepping. I try to keep the bucket, path, and schema all on the same line as the import_parse() for this reason.

For big files you typically want to specify a timeout (usually 4-5x what you see it do normally on 0xdata machines, so it works on ec2)
You may also want to compensate for # of machines if you know it varies. For instance, you might multiple by len(h2o.nodes)
    timeoutSecs = 500 + (500/len(h2o.nodes))

    parseResult = h2i.import_parse(bucket='home-0xdiag-datasets', path=csvPathname, schema='local', timeoutSecs=500)

timeouts are important, because long parses can take up to 30 minutes or so. You don't want to use a 30 minute timeout on all parses
(although we poll the sandbox for h2o stack traces, so regardless of timeout, if h2o blows up, the test should detect that while polling for parse completion and fail immediately)

but timeouts are important for monitoring h2o performance too..i.e. performance expectations.

Now you may ask, what does this have to do with cats, and what I'm familar with in the browser..i.e. upload of a single file, or importfiles with a possible pattern match.

well, the csvPathname above, which is an offset in the bucket, can be a single file, or a regex at the end.
i.e.

   csvPathname = "dir1/dir2/dir3/file[0-3]*.gz

Import, if done on multiple machines, needs the exact same file, in the exact same place, on all machines. putfile (upload) only needs one copy of the file, on the machine doing the python.

A putfile (upload in the browser) can only be a single file..plus it's slower than doing an import (putfile was initially the only h2o ingest method). Still useful for muli machine since the file only needs to be one place locally. Most of the tests still use schema='put" for small datasets.

i.e
  csvPathname = "dir1/dir2/dir3/file0_1.gz
  parseResult = h2i.import_parse(bucket='home-0xdiag-datasets', path=csvPathname, schema='put', timeoutSecs=500)

Note how the variety of h2o behaviors are all nicely covered with the same import_parse()
(and it does s3/s3n/hdfs/maprfs also, plus finds the bucket (for 'local' or 'put') wherever you've stashed it)
configurable setup class
git rid of sigar param to build cloud. Increment ports from 8000 base for attached debugger to jvms (java command line stuff)
pass some extra info about how the cloud was built in h2o-nodes.json, that the test-only cloud clone can save for knowing how to rebuild the cloud on test failure.
Merge remote-tracking branch: upstream/master