Mason: Provide moving parts needed for testing on OpenStack

Testing currently involves building a Baserock devel system,
deploying it as a VM and testing that that deployed VM can
build Baserock successfully.

Originally Mason used scripts/release-test to do testing on
a kvm host.  In this patch the bits needed to do testing on
an OpenStack host are provided.

The new scripts/release-test-os script is based on the old
scripts/release-test, and it uses `nova` to boot/delete/etc
images and instances on OpenStack.

The mason script, `mason.sh` is updated to optionally run
either scripts/release-test-os or scripts/release-test,
depending on whether TEST_INFRASTRUCTURE_TYPE is set to
'openstack' or 'kvmhost' in the Mason's mason.conf.

The `os.conf` file is sourced by `mason.sh`, and should
be updated to contain the relevant credentials and details
for the OpenStack tenancy to be used for test deployments.

When Mason creates a test OpenStack instance, there is
potential for a race condition depending on whether ssh
comes up before the cloud-init has finished resizing the
instance's disc.  If morph running on the test instance
tries to build before the disc size is increased, it will
fail complaining of insufficient free space.

To eliminate this race, the cloud init script
`os-init-script` is passed to `nova boot`.  This touches
a file after the disc is resized, which Mason checks for
before it runs a `morph build`.

The `os.conf` and `os-init-script` files must both be
placed in the Mason system's `/root/` directory before
the system is deployed.  This should happen in the
`mason.configure` configuration extension.

The `mason.configure` configuration extension should also
be updated to handle adding two extra variables to the
`mason.conf` file.  These are the aforementioned
TEST_INFRASTRUCTURE_TYPE and OPENSTACK_NETWORK_ID, which is
the ID for the configured OpenStack network that test
instances should use.

3 files changed, 53 insertions, 5 deletions

diff --git a/mason/mason.sh b/mason/mason.sh
index 32aab032..7b56b8cc 100755
--- a/mason/mason.sh
+++ b/mason/mason.sh
@@ -1,5 +1,8 @@
 #!/bin/sh
 
+# Load OpenStack credentials
+. /root/os.conf
+
 set -e
 set -x
 
@@ -59,11 +62,20 @@ else
     echo INFO: Created "$releases_made" release images
 fi
 
-"scripts/release-test" \
-	--deployment-host "$DISTBUILD_ARCH":"$TEST_VM_HOST_SSH_URL" \
-	--trove-host "$UPSTREAM_TROVE_ADDRESS" \
-	--trove-id "$TROVE_ID" \
-	"$BUILD_CLUSTER_MORPHOLOGY"
+if [ "$TEST_INFRASTRUCTURE_TYPE" = "openstack" ]; then
+    "scripts/release-test-os" \
+        --deployment-host "$DISTBUILD_ARCH":"$TEST_VM_HOST_SSH_URL" \
+        --trove-host "$UPSTREAM_TROVE_ADDRESS" \
+        --trove-id "$TROVE_ID" \
+        --net-id "$OPENSTACK_NETWORK_ID" \
+        "$BUILD_CLUSTER_MORPHOLOGY"
+elif [ "$TEST_INFRASTRUCTURE_TYPE" = "kvmhost" ]; then
+    "scripts/release-test" \
+        --deployment-host "$DISTBUILD_ARCH":"$TEST_VM_HOST_SSH_URL" \
+        --trove-host "$UPSTREAM_TROVE_ADDRESS" \
+        --trove-id "$TROVE_ID" \
+        "$BUILD_CLUSTER_MORPHOLOGY"
+fi
 
 "scripts/release-upload" --build-trove-host "$ARTIFACT_CACHE_SERVER" \
 	--arch "$DISTBUILD_ARCH" \
diff --git a/mason/os-init-script b/mason/os-init-script
new file mode 100644
index 00000000..77afb926
--- /dev/null
+++ b/mason/os-init-script
@@ -0,0 +1,6 @@
+#!/bin/bash
+
+# This allows the test runner to know that cloud-init has completed the
+# disc resizing, and there is enough free space to continue.
+touch /root/cloud-init-finished
+
diff --git a/mason/os.conf b/mason/os.conf
new file mode 100644
index 00000000..3c5d0ef9
--- /dev/null
+++ b/mason/os.conf
@@ -0,0 +1,30 @@
+#!/bin/bash
+
+# A version of this file with the relevant information included can be
+# obtained by navigating to 'Access & Security' -> 'API Access' -> 
+# 'Download OpenStack RC file' in The Horizon web interface of your
+# OpenStack. However, the file obtained from there sets OS_PASSWORD
+# such that it will ask the user for a password, so you will need to
+# change that for Mason to work automatically.
+#
+# With the addition of Keystone, to use an openstack cloud you should
+# authenticate against keystone, which returns a **Token** and **Service
+# Catalog**.  The catalog contains the endpoint for all services the
+# user/tenant has access to - including nova, glance, keystone, swift.
+#
+# *NOTE*: Using the 2.0 *auth api* does not mean that compute api is 2.0.  We
+# will use the 1.1 *compute api*
+export OS_AUTH_URL=<os-auth-url>
+
+# With the addition of Keystone we have standardized on the term **tenant**
+# as the entity that owns the resources.
+export OS_TENANT_ID=<os-tenant-id>
+export OS_TENANT_NAME="<os-tenant>"
+
+# In addition to the owning entity (tenant), openstack stores the entity
+# performing the action as the **user**.
+export OS_USERNAME="<os-user>"
+
+# With Keystone you pass the keystone password.
+export OS_PASSWORD="<os-pass>"
+