I figure it will take time to develop a consensus on how python tests should be written.
So I'm going to have this py2 dir for now.
Code is in sync with the refactored h2o1 python
It has the new -uc/--usecloud parameter (which also can be pass in a config json file) to connect to a prebuilt cloud but it also supports all the cloud build methodologies of the h2o1 cloud building/logging (multijvm/multinode/single jvm etc)

All the normal logs in sandbox
Just put the minimal library modules in to get a test to pass, and only changed what was needed  to get cloud build working

Only supports get_cloud to h2o

this test passes with hacks around stuff I mentioned in email (at least like this, I didn't try multinode or with a config json or with -uc/--usecloud but that works in h2o1, so should just work here)

 cd py2/testdir_single_jvm
 python test_simple.py

You can example that file, and see the new h2o.init() which takes the same params as before, but does all the decisionmaking about existing clouds, creating clouds, parameters to h2o etc, outside of the test (no if decided_if_localhost)

h2o.py is a placeholder for indirecting to other files. I think it general tests will be modified to not require any additional stuff there (i.e. point to the new file directly)...but will see what feels right.

Ray has plans for how to expand h2o_methods.py to get autogen for h2o request params and returned json object.
All h2o requests are considered methods hanging off of h2o.nodes (which is really h2o_nodes.nodes)

So the concept, like h2o1, is a collection of nodes, which have some state (mostly reflecting how the java -jar was started..params..but other catchall state dumped in to). ....and then there are methods on the base H2O defintion

The full collection of objects (like h2o1) are: RemoteHost (only used if building multi-node with config json), LocalH2O, RemoteH2O, and ExternalH2O. These are all the same as h2o1.

Depending on what kind of node object you are, you have some method differences (same as h2o1)

I'm thinking I'll also have h2o_cmd() like before, for optional use, which is a functional api that calles the node level methods. (like existing h2o_cmd.runRF)

Note our R package already introduces a functional api that's different than the h2o node api (it tries to track existing R packages).
Merge branch 'master' of https://github.com/0xdata/h2o-dev