Jetlag CI stuff

[webbnh]

This PR creates a holding area for materials which might be used to create a Jetlag continuous integration (CI) system, to automate building and testing of Jetlag for development and quality assurance.

This PR, in addition to adding a CI subdirectory and a README.md for it, adds one file, deploy_sno.sh, which is an initial effort at scripting the deployment of a single-node OpenShift cluster using Jetlag. It is targeted at a Scale Lab deployment, but the techniques it uses should be applicable across all deployments. It is currently somewhat opinionated, but it should be straightforward to generalize it.

This PR is not necessarily intended to be merged; rather, it's a placeholder, to give visibility for this file in the event that someone wants to use it as the basis for a CI runner, e.g., for Jenkins.

[dbutenhof]

Cool, thanks for the "running start".

[dbutenhof]

Expand ${N} into ON_BASTION and then define N? Interesting strategy. Or did you mean ON_BASTION='${N} ...' to defer substitution until later?

[webbnh]

Those are excellent questions. I concur that the code as it stands looks suspiciously like a botch.

Unfortunately, the requirements for a "dry-run" are less than cut and...er...dried. In one conception, one would like to be able to run the script without it actually requiring or expending any resources. But, if that execution takes place only on the local node, it gets pretty boring pretty fast. A more interesting scenario involves doing a "dry run" but including the parts which execute on the bastion as well, but doing them as a dry-run. In that case, the code above does the "right thing": it actually executes the ssh command but the commands that that executes get the ${N} treatment. (However, once the mechanics of that work, then even that becomes boring...so, we should probably just tear out the whole ${N} thing altogether.)