| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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_INFRA 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_INFRA
and OPENSTACK_NET_ID, which is the ID for the configured
OpenStack network that test instances should use.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
This prevents discovering changes, and then being unable to build them
because the local trove has not yet got them.
|
| |
|
|
|
|
| |
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.
|
