| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This is useful if you have a distbuild controller with a non-standard
port.
It now also warns if something couldn't be built because there is no
build network for that arch available.
Change-Id: I5fcac2be9aa198afe16b76564d8307fed04bd526
|
|
|
|
|
|
| |
See schemas/README.schemas for information.
Change-Id: I6c384692dbf70017a3ece2ed56c1f8cbe60b493d
|
|
|
|
|
| |
Signed-off-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Change-Id: I1c8d2ed5d9c06466bdaac1c1e914f5f9e3969e11
|
|
|
|
| |
Change-Id: Id3b868db36554541334dae3bd6363d5adc0289b8
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| | |
'origin/baserock/ps/cycle-refuses-to-delete-TEST-system'
Reviewed-by: Richard Maw (+2)
|
|/ |
|
|
|
|
|
| |
Reviewed-by: Paul Sherwood
Reviewed-by: Sam Thursfield
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This requires the script be run in the top of the definitions repository,
but will actually try to upload the changes that were tested, rather
than the current HEAD.
|
| |
|
|
|
|
|
| |
The rest of the ssh commands are to the VM host, which we can't change
all of, since some are run as part of the deployment extension.
|
| |
|
|
|
|
| |
This name requires less context to understand its use.
|
| |
|
| |
|
|
|
|
| |
It was a sucky placeholder name that wasn't replaced by anything better.
|
| |
|
|
|
|
|
| |
This will deploy and run build tests on systems listed in the morphology
passed as its first argument.
|
|
|
|
| |
This makes the release-upload script more versatile.
|
| |
|
| |
|
| |
|
|
|
|
| |
For comprehensibility.
|
| |
|
|
|
|
|
| |
Avoiding a condition that has a negation tends to be a bit simpler
for humans to understand.
|
|
|
|
|
| |
Move stuff into new methods to make overall logic clearer and to
avoid stuffing too much into each method.
|
| |
|
| |
|
|
|
|
|
| |
There used to be a check that prevented deployments with names different
to the system. I don't know why this was, but I don't think we need it.
|
|
|
|
|
| |
Without this change the rsync and xargs commands will wait forever for
input that will never arrive.
|
|
|
|
|
|
|
|
|
|
|
| |
We currently build all architectures at once during the release process,
however for our CD pipeline we operate with one CD pipeline per
architecture.
This is not just useful for the CD pipeline work though, as it allows
one organisation to handle releases for x86, where the infrastructure
may be located in the cloud, and one organisation to handle ARM systems,
which may be located in an office.
|
|
|
|
|
|
|
|
|
| |
For continuous artifact cache population, we don't care so much about
the large disk images that we make available at release time.
This patch allows omitting any of the configuration required to upload
the release images to mean that we didn't want to upload them, and
continue without doing so.
|
| |
|
|
|
|
|
|
|
|
| |
The script used to chdir into the release directory before running morph
deploy. Unfortunately, this didn't work because deployments are run from
the top of the definitons repository.
So now the release directory is included in the path to be deployed.
|
| |
|
|
|
|
| |
Suggested-by: Sam Thursfield
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These scripts are a rewrite of scripts/do-release.py and
scripts/distbuild-cluster. The biggest difference is that they split
the tasks of building the things that are to be released, and uploading
them to git.baserock.org / download.baserock.org, where do-release.py
combines both (and distbuild-cluster only builds chunk/stratum/system
artifacts, not the release images). The new scripts are also configurable
using command line options or a configuration file rather than requiring
editing of the source.
These changes will allow, for example, a CI job that builds a release,
but doesn't upload it to download.baserock.org.
The new scripts are coupled with a change to the release process, which
will be documented as a change to the release process page on
wiki.baserock.org.
The 14.29 release of Baserock was done with slightly different versions
of these scripts to make it feasible to upload things over multiple
network connections.
|
|
|
|
|
| |
Fix string quoting.
Put all stuff that needs changed in angle brackets.
|
|
|
|
| |
Replaces references to `master` with release tag name.
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| | |
- Adds ability to pass cluster, ref and distbuild controller
hosts on the command line.
- Adds --help, and usage.
- Prints the specified parameters out.
|
|/
|
|
|
| |
Remove a comment that is no longer true, fix a formatting error, and
add a docstring to a class that lacked one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'morph deploy' command now lets us deploy system images one at a
time, so let's do that. This means that if all but one image is
deployed successfully, on the next run the user just needs to deploy
one further image.
Also, since each deployment has a unique name in release.morph now,
we can override the location and VERSION_LABEL fields instead of
requiring the user to update them manually before each release. The
release.morph cluster should now specify the *basename* of the image
in the location field only. By basename, I mean the system name plus
the appropriate extension (normally .tar or .img). The do-release
script will then prepend the image path and the version label to get
a filename.
The release.morph cluster has been updated accordingly.
|