| 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_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.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Daniel Silverstone <daniel.silverstone@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| | |
These strata used to be in all devel systems and were removed. The only
extra component that a system needs to be a Vagrant basebox is the
VirtualBox Guest Additions, which are in the virtualbox-guest-x86_64
stratum.
|
| |
| |
| |
| |
| |
| |
| | |
These are dependencies of the Baserock Import tool. The import tool will
be added to the devel system later, in a separate branch.
This increases the size of an x86_32 devel system from 1.1GB to 1.2GB.
|
| |
| |
| |
| |
| |
| |
| | |
The build-system is equivalent in functionality to the current
devel-system that we release, but this change allows us to add more
components to the devel-system without increasing the amount of bytes we
have to arrange and transfer when making a release.
|
| |
| |
| |
| |
| | |
These take the place of the devel system chroots that we released
previously, and should be functionally equivalent.
|
| |
| |
| |
| |
| |
| | |
The 'build' system is now the recommended way of building other systems,
with 'devel' being a larger variant of 'build' that may be useful when
doing development and integration, in addition to building and deployment.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This partially reverts ced256bda95f184361815a6444d752ee10d86d02
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-By: Adam Coldrick <adam.coldrick@codethink.co.uk>
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
| | | |
| | | |
| | | |
| | | | |
Various Gems require one or other of these tools at build time.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The new version of lorry-controller includes a script to
remove the log of old jobs that nobody cares about.
The new version of trove-setup is needed to enable a new systemd
unit created in lorry-controller to run the new script.
|
| |_|/
|/| | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | |
| | |
| | |
| | |
| | | |
It had lots of unneccessary stuff and wouldn't build.
Have removed unneccessary stuff; is now just base system plus node.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-By: James Thomas <james.thomas@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In this way we can build completely wayland-only systems
The reason to do this is that cairo will pull the X11 dependency if the
mesa stratum is built with X11 support (as graphics-common depens on
mesa-common)
|
| | | |
| | | |
| | | |
| | | |
| | | | |
As libdrm was moved to an independent stratum this only holds
some macros needed to compile other strata
|
| | | |
| | | |
| | | |
| | | | |
So libdrm only gets build when it's really needed
|
| |/ /
| | |
| | |
| | | |
With basic infrastructure components like libdrm and xorg macros
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| |/
|/|
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| | |
'origin/baserock/ps/cycle-refuses-to-delete-TEST-system'
Reviewed-by: Richard Maw (+2)
|
| | |
|
|\ \
| |/
|/|
| |
| |
| | |
Change-Id: I96d767050b7261cb9e4ec1ff6ce8fa1865bf51ab
Reviewed-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-by: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
|
|/
|
|
| |
Change-Id: I1f77fc4c23335f838f1b1f4b4ddaa8da355dab8f
|
|\
| |
| |
| |
| | |
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
--disable-assertions: those checks are not needed in production systems
--enable-optimized: it will help compiling on ARM
--enable-shared: mesa recommends llvm to be compiled in this way
--enable-targets=host: Only build for the host architecture
See http://llvm.org/docs/GettingStarted.html#local-llvm-configuration and
http://llvm.org/docs/HowToBuildOnARM.html
|
| |
| |
| |
| | |
Seems 3.4.2 and 3.5.1 doesnt compile in ARM
|
| |
| |
| |
| |
| | |
llvm is a bif piece of software that take long time to build
With this move we will only build it when its really necessary
|
| | |
|
|\ \
| | |
| | |
| | | |
This updates morph and ensures the new dependencies are available.
|
| | |
| | |
| | |
| | |
| | | |
morph now contains distbuild and morph-cache-server, so the distbuild
stratum can go away, and anything that needs it can now use morph.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Richard Maw
Reviewed-by: Sam Thursfield
Reviewed-by: Francisco Redondo Marchena
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some users think that adding the cloud-init configuration
extension to a system is enough to install and enable cloud-init.
This is not true, to add and enable cloud-init in a system the
system has to have cloud-init installed (cloud-init chunk) and
cloud-init services have to be enabled (with cloud-init
configuration extension)
This patch is to alert the user that cloud-init can't be enabled
in a system without cloud-init installed, and making the
deployment fail.
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
Reviewed-By: Richard Ipsum (on IRC)
Reviewed-By: Francisco Redondo Marchena (on IRC)
|
|/ / |
|