| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This is for an old implemenation of Mason. The more recent
implementations don't need special configuration to be done on the
Trove.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Java is sourced from the binary Java release from Oracle. This
chunk was originally written by Francisco Marchena.
ANT is a Java build system and is needed by ZooKeeper.
ZooKeeper itself is documented at http://zookeeper.apache.org/
This patch also brings in a zookeeper test program in a seperate strata
that can be safely discarded if not required. this test program
was written by me, <mike.smith@codethink.co.uk> and is not designed to
be used in any practical way, but to showcase the functionality
of zookeeper within baserock
The ZooKeeper demonstration server and client are currently hosted
on baserock/test.
The Java binary chunk only works for x86_64. As such, these
systems are limited to that architecture.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The installer-x86_64 system is a system that can be used to install other
systems in an storage device. This system is intended to be booted by usb,
pxeboot... to install a Baserock system in your local disk.
The installer system requires the installer.configure extension to generate
a configuration file located in /etc/install.conf. With this extension
you can specify the following variables in a cluster morphology:
- INSTALLER_TARGET_STORAGE_DEVICE: Target storage device to install the
Baserock system.
- INSTALLER_ROOTFS_TO_INSTALL: The location of the root filesystem that
is going to be installed.
- INSTALLER_POST_INSTALL_COMMAND: Commands that will be run after the
installation finishes. It defaults to `reboot -f`.
The installer-utils stratum is required to contain the installer-scripts
chunk. This chunk contains the installer script that is going to be
installed in /usr/lib/installer/installer.py
The clusters/installer-build-system-x86_64.morph file defines the deployment
of a installer system as a rawdisk image. This installer system will
install a build-system-x86_64 located in /rootfs into the /dev/sda device.
Also this cluster defines a subsystem which is the build-system that
is going to end up in /rootfs on the installer system.
|
| |
|
|
|
|
|
|
|
|
| |
This will compile almost all the strata available in baserock related
on building Linux systems (kernel, systemd, connectivity, multimedia, wayland,
weston...).
This will also make the artifacts cache available to anyone that want
to build starting from this reference system
|
| |
|
| |
|
|
|
|
|
| |
Now the build systems have the openstack-clients stratum,
and this system is not longer needed.
|
|
|
|
|
| |
This will avoid problems when self-upgrading a system and also
will save time when flashing a JETSON TK1 board.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes localhost does not resolve, which makes rsync to
root@localhost fail during upgrades with:
ERROR: ssh-rsync.check failed with code 1: ERROR: Unable to SSH to
root@localhost: Command failed: ssh root@localhost -- true
ssh: connect to host localhost port 22: Connection timed out
So let's set the default to 127.0.0.1, which should always work.
|
|
|
|
|
|
| |
This could be improved in future by combining the cluster morphology
with the existing one, and mason/mason-generator.sh being improved to
allow choice between OpenStack and KVM.
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Daniel Silverstone <daniel.silverstone@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Make the name of the Jetson-specific linux morph file consistent
with the others, and add the jetson-upgrade cluster
|
| |
|
|
|
|
|
| |
We don't need to store gits on there, so we don't need it to be quite so
large.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|