Deploying new synth with otcetera services

See Late-2019-tree-deployment-steps

Steps for deploying a new tree from 2017 are at https://github.com/OpenTreeOfLife/germinator/blob/master/new_synthetic_tree.md

@bredelings and @mtholder are working on reimplementation of tm-lite and conflict services focused on:

1. low RAM requirements,
2. easy deployment of a new tree,
3. flexibility (particularly wrt the conflict service inputs), and
4. maintainability of the code (particularly wrt treemachine code which was originally the tree synth engine).

Sketch of desired pipeline

It seems nice for users to be able to see "current", "previous", and "next" versions of the tree.

The schedule would be something like:

1. frequently: build new PATCH-level candidate release. Visible to users as "next" tree with: * rapidly changing "PATCH" version numbers, * synth output tar ball only stored for current PATCH for a given MINOR version * complete store all needed SHAs for all PATCH versions * serve a diff log from previous MINOR version for each PATCH * serve a diff log comparing to previous PATCH in this MINOR series
2. periodically (e.g. monthly or as needed) bump "current" -> "previous" and "next" -> "current" * this freezes the last PATCH what becomes the "current" tree. * the previous "previous" tree is no longer served, but available as an archive. * Usually, this would roll the PATCH version to 0 and increment the MINOR version number. For big changes (or big taxonomy changes) this step would roll MINOR to 0 and increment the MAJOR.

Updating to the next in a PATCH

Redeploying a tree should entail:

1. building the tree with propinquity
2. compressing the output
3. scp archive to the api server.
4. nudge a private API method to tell the server to check for a new version of the synth tree.

implementation proposal

building and pushing

1. improve propinquity's version detection to call a (as yet unwritten) http://api.opentreeoflife.org/get_next_synth_patch_version(bool bump_minor=False, bool bump_major=False) web service call.
2. write this to the propinquity config file.
3. build as we currently do
4. tar and compress as we currently do
5. scp propinquity-out.tar.gz api:~/uploading/opentree{#} && ssh -t api "mv ~/uploading/opentree{#} ~/staged/opentree{#}

nudge API server

http://api.opentreeoflife.org/check_for_newly_deployed_tree triggers a check of the local filesystem for the next version of the tree. If found it can:

1. validate contents of archive
2. launch a local instance of the otcetera web service on the appropriate port
3. if that works, store in memory the mapping of version # to port #
4. push tar balls to files
5. write and push release notes
6. write and push new version of a statistics file