| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
This adds TEST_INFRASTRUCTURE_TYPE and OPENSTACK_NETWORK_ID to
mason.conf, as well as ending the confusion of using both
MASON_TEST_HOST and TEST_VM_HOST_SSH_URL to mean the same thing
in different places.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's better to have one type of system that can do either distributed or
local builds than to have separate ones that must both be kept up to
date with changes.
The need for a separate 'distbuild' stratum went already:
commit 1a7fbedf56a4c7a6afb683851dde5d34bbb48b86
Author: Richard Maw <richard.maw@codethink.co.uk>
Date: Thu Oct 2 14:16:00 2014 +0000
Split morph out of tools
morph now contains distbuild and morph-cache-server, so the distbuild
stratum can go away, and anything that needs it can now use morph.
|
| |
|
|
|
|
|
|
| |
- Move the configuration file to /etc/mason.conf
- Move the scripts to /usr/lib/mason/
- Mason will store the report in /var/mason/report.html
|
|
|
|
|
|
|
|
| |
Now that we use the upstream trove, rather than local trove for git,
the report generator needs to be updated to reflect that.
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The per-mason trove only needs to worry about being an artifact cache,
so we can prevent it populating itself from the upstream trove by making
it use the SSH protocol for fetching sources, and not registering its
ssh key with the upstream trove.
The MASON_UPSTREAM_TROVE_ADDRESS option has been removed, as this is now
the TROVE_HOST.
The distbuild network is now configured to use the upstream trove for
sources, and the local trove for artifacts, with the
ARTIFACT_CACHE_SERVER option.
mason.configure now uses ARTIFACT_CACHE_SERVER to tell deploy commands
which server to fetch artifacts from.
|
| |
|
|
|
|
|
|
|
|
| |
Add a note showing how to copy the mason controller's id_rsa.key.pub
to the upstream trove. This is needed or else artifact upload will
now work, resuling in a FAIL.
Reviewed-By: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Failing to do this means that the deployment uses the wrong morphology,
because build will end up using the repo without the .git suffix, so it
will never update the cached version of the repo without it.
The version with the .git suffix is only updated on the initial
checkout, but is used by deploy, so it would pick up obsolete
morphologies and not include new changes.
Rubber-stamped-by: Richard Maw
|
| |
|
|
|
|
|
|
|
|
|
| |
Now the timestamp of the last time we looked for any changes in
the definitions.git repository is put into the footer area. It
is highlighted for visibility.
This makes it easier to see that the mason system is still
running, but that there is nothing new to build.
|
|
|
|
| |
This reduces flicker/churn when browsing a mason report page.
|
|
|
|
|
| |
This prevents discovering changes, and then being unable to build them
because the local trove has not yet got them.
|
|
|
|
|
| |
Reviewed-By: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
|
|
|
|
|
| |
If the git remote update command fails, we assume it's because
we are unable to connect to the trove. This gets reported as a
networking issue, rather than as a failure.
|
|
The distbuild system can be configured to act as a CI controller.
Providing appropriate config makes it copy all the scripts and systemd
units out of the mason directory onto the target, such that it will
start building and testing the configured cluster morphology on boot.
|