summaryrefslogtreecommitdiff
path: root/clusters
diff options
context:
space:
mode:
Diffstat (limited to 'clusters')
-rw-r--r--clusters/ci.morph14
-rw-r--r--clusters/example-distbuild-cluster.morph37
-rw-r--r--clusters/gitlab-ci-runner-cluster.morph16
-rw-r--r--clusters/gitlab-cluster.morph48
-rw-r--r--clusters/gitlab-server-cluster.morph22
-rw-r--r--clusters/image-package-example.morph12
-rw-r--r--clusters/initramfs-test.morph17
-rw-r--r--clusters/mason.morph57
-rw-r--r--clusters/minimal-system-deploy.morph14
-rw-r--r--clusters/release.morph50
-rw-r--r--clusters/sdk-example-cluster.morph46
-rw-r--r--clusters/trove.baserock.org-upgrade.morph23
-rw-r--r--clusters/upgrade-devel.morph39
13 files changed, 395 insertions, 0 deletions
diff --git a/clusters/ci.morph b/clusters/ci.morph
new file mode 100644
index 00000000..f860a4ba
--- /dev/null
+++ b/clusters/ci.morph
@@ -0,0 +1,14 @@
+name: ci
+kind: cluster
+description: |
+ Deploy all the systems for CD.
+
+ This cluster morph is for use by the Mason Continuous Delivery pipeline
+ during development.
+systems:
+- morph: systems/devel-system-x86_64-generic.morph
+ deploy:
+ devel-system-x86_64-generic:
+ type: rawdisk
+ location: devel-system-x86_64-generic.img
+ DISK_SIZE: 4G
diff --git a/clusters/example-distbuild-cluster.morph b/clusters/example-distbuild-cluster.morph
new file mode 100644
index 00000000..4c97d21f
--- /dev/null
+++ b/clusters/example-distbuild-cluster.morph
@@ -0,0 +1,37 @@
+name: example-distbuild-cluster
+kind: cluster
+description: |
+ This is an example cluster morph that can be adapted to set up a
+ Baserock distributed build network.
+
+ You will need to deploy a Trove for the distributed build network
+ to use before deploying this cluster. The worker SSH key file should
+ be generated as part of the Trove deployment. It is the key used by
+ workers to authenticate with the Trove to give them read access to
+ all source repositories.
+systems:
+- morph: systems/distbuild-system-x86_64-generic.morph
+ deploy-defaults:
+ CONTROLLERHOST: build-controller
+ DISTBUILD_CONTROLLER: false
+ DISTBUILD_WORKER: true
+ FSTAB_SRC: LABEL=src /srv/distbuild auto defaults,rw,noatime 0 2
+ INSTALL_FILES: distbuild/manifest
+ NFSBOOT_CONFIGURE: true
+ TROVE_ID: $MY_TROVE
+ WORKER_SSH_KEY: ssh-keys/worker.key
+ deploy:
+ build-controller:
+ type: nfsboot
+ location: $MY_TROVE
+ DISTBUILD_CONTROLLER: true
+ HOSTNAME: build-controller
+ WORKERS: build-node-1, build-node-2
+ build-node-1:
+ type: nfsboot
+ location: $MY_TROVE
+ HOSTNAME: build-node-1
+ build-node-2:
+ type: nfsboot
+ location: $MY_TROVE
+ HOSTNAME: build-node-2
diff --git a/clusters/gitlab-ci-runner-cluster.morph b/clusters/gitlab-ci-runner-cluster.morph
new file mode 100644
index 00000000..97da4a8d
--- /dev/null
+++ b/clusters/gitlab-ci-runner-cluster.morph
@@ -0,0 +1,16 @@
+name: gitlab-ci-runner-cluster
+kind: cluster
+systems:
+- morph: systems/gitlab-ci-runner.morph
+ deploy-defaults:
+ AUTOSTART: false
+ DISK_SIZE: 6G
+ RAM_SIZE: 3G
+ VCPUS: 2
+ VERSION_LABEL: factory
+ deploy:
+ gitlab-ci-runner:
+ type: kvm
+ location: kvm+ssh://USER@HOST/gitlab-ci-runner/home/USER/gitlab-ci-runner.img
+ HOSTNAME: gitlab-ci-runner
+ INSTALL_FILES: gitlab-ci-runner/manifest
diff --git a/clusters/gitlab-cluster.morph b/clusters/gitlab-cluster.morph
new file mode 100644
index 00000000..5f3177ca
--- /dev/null
+++ b/clusters/gitlab-cluster.morph
@@ -0,0 +1,48 @@
+name: gitlab-cluster
+kind: cluster
+description: |
+ This is an example cluster morphology that can be adapted to set up a GitLab
+ server with GitLab CI running alongside it, along with one or more CI
+ runners to actually run the CI tests/builds.
+
+ For the server, you will need to specify the GITLAB_HOSTNAME. This is the
+ domain name or IP by which your deployed GitLab instance will be able to be
+ reached by. You will also need a GITLAB_PORT, CI_PORT, UNICORN PORT and
+ UNICORN_CI_PORT. These are the port to use for GitLab, the port to use for
+ GitLab CI, the port for GitLab's Unicorn process to listen on, and the port
+ for GitLab CI's Unicorn process to listen on respectively. Finally, you will
+ need to define a GITLAB_EMAIL, that is the email that mail from your GitLab
+ instance will appear to be from.
+systems:
+- morph: systems/gitlab-server.morph
+ deploy-defaults:
+ AUTOSTART: false
+ DISK_SIZE: 10G
+ RAM_SIZE: 2G
+ VCPUS: 2
+ VERSION_LABEL: factory
+ deploy:
+ gitlab:
+ type: kvm
+ location: kvm+ssh://USER@HOST/gitlab/home/USER/gitlab.img
+ CI_PORT: 81
+ GITLAB_EMAIL: gitlab@gitlab.example.com
+ GITLAB_HOSTNAME: gitlab.example.com
+ GITLAB_PORT: 80
+ HOSTNAME: gitlab
+ INSTALL_FILES: gitlab-server/manifest
+ UNICORN_CI_PORT: 8081
+ UNICORN_PORT: 8080
+- morph: systems/gitlab-ci-runner.morph
+ deploy-defaults:
+ AUTOSTART: false
+ DISK_SIZE: 10G
+ RAM_SIZE: 3G
+ VCPUS: 2
+ VERSION_LABEL: factory
+ deploy:
+ gitlab-ci-runner:
+ type: kvm
+ location: kvm+ssh://USER@HOST/gitlab-ci-runner/home/USER/gitlab-ci-runner.img
+ HOSTNAME: gitlab-ci-runner
+ INSTALL_FILES: gitlab-ci-runner/manifest
diff --git a/clusters/gitlab-server-cluster.morph b/clusters/gitlab-server-cluster.morph
new file mode 100644
index 00000000..fcb7c1d2
--- /dev/null
+++ b/clusters/gitlab-server-cluster.morph
@@ -0,0 +1,22 @@
+name: gitlab-server-cluster
+kind: cluster
+systems:
+- morph: systems/gitlab-server.morph
+ deploy-defaults:
+ AUTOSTART: false
+ DISK_SIZE: 6G
+ RAM_SIZE: 2G
+ VCPUS: 2
+ VERSION_LABEL: factory
+ deploy:
+ gitlab:
+ type: kvm
+ location: kvm+ssh://USER@HOST/gitlab/home/USER/gitlab.img
+ CI_PORT: 81
+ GITLAB_EMAIL: gitlab@gitlab.example.com
+ GITLAB_HOSTNAME: gitlab.example.com
+ GITLAB_PORT: 80
+ HOSTNAME: gitlab
+ INSTALL_FILES: gitlab-server/manifest
+ UNICORN_CI_PORT: 8081
+ UNICORN_PORT: 8080
diff --git a/clusters/image-package-example.morph b/clusters/image-package-example.morph
new file mode 100644
index 00000000..fd8487e2
--- /dev/null
+++ b/clusters/image-package-example.morph
@@ -0,0 +1,12 @@
+name: image-package-example
+kind: cluster
+description: |
+ Packaged system and script for installing it, for deferred instantiation.
+systems:
+- morph: systems/base-system-x86_32-generic.morph
+ deploy:
+ imgpkg:
+ type: image-package
+ location: image-package-example.tar
+ BOOTLOADER_BLOBS: /usr/share/syslinux/mbr.bin
+ INCLUDE_SCRIPTS: image-package-example/make-disk-image.sh.in:image-package-example/disk-install.sh.in:image-package-example/common.sh.in
diff --git a/clusters/initramfs-test.morph b/clusters/initramfs-test.morph
new file mode 100644
index 00000000..afc94961
--- /dev/null
+++ b/clusters/initramfs-test.morph
@@ -0,0 +1,17 @@
+name: initramfs-test
+kind: cluster
+systems:
+- morph: systems/base-system-x86_64-generic.morph
+ deploy:
+ system:
+ type: rawdisk
+ location: initramfs-system-x86_64.img
+ DISK_SIZE: 1G
+ HOSTNAME: initramfs-system
+ INITRAMFS_PATH: boot/initramfs.gz
+ subsystems:
+ - morph: systems/initramfs-x86_64.morph
+ deploy:
+ initramfs:
+ type: initramfs
+ location: boot/initramfs.gz
diff --git a/clusters/mason.morph b/clusters/mason.morph
new file mode 100644
index 00000000..1aa2dadb
--- /dev/null
+++ b/clusters/mason.morph
@@ -0,0 +1,57 @@
+name: example-mason-cluster
+kind: cluster
+description: |
+ This is a template cluster morphology that can be adapted to set up a
+ Mason. Masons are composed of a trove and a distbuild system.
+
+ It is suggested that you use mason/mason-generator.sh to adapt this
+ template to suit your needs. It also handles the generation of
+ keys to let the systems communicate.
+systems:
+- morph: systems/trove-system-x86_64.morph
+ deploy:
+ red-box-v1-trove:
+ type: kvm
+ location: kvm+ssh://vm-user@vm-host/red-box-v1-trove/vm-path/red-box-v1-trove.img
+ AUTOSTART: true
+ DISK_SIZE: 100G
+ HOSTNAME: red-box-v1-trove
+ LORRY_SSH_KEY: ssh_keys/lorry.key
+ MASON_SSH_PUBKEY: ssh_keys/mason.key.pub
+ RAM_SIZE: 8G
+ TROVE_ADMIN_EMAIL: adminuser@example.com
+ TROVE_ADMIN_NAME: Nobody
+ TROVE_ADMIN_SSH_PUBKEY: ssh_keys/id_rsa.pub
+ TROVE_ADMIN_USER: adminuser
+ TROVE_COMPANY: Company name goes here
+ TROVE_HOST: red-box-v1
+ TROVE_ID: red-box-v1-trove
+ UPSTREAM_TROVE: upstream-trove
+ UPSTREAM_TROVE_PROTOCOL: http
+ VCPUS: 2
+ VERSION_LABEL: 45
+ WORKER_SSH_PUBKEY: ssh_keys/worker.key.pub
+- morph: systems/distbuild-system-x86_64.morph
+ deploy-defaults:
+ CONTROLLERHOST: red-box-v1-controller
+ DISTBUILD_CONTROLLER: false
+ DISTBUILD_WORKER: true
+ INSTALL_FILES: distbuild/manifest
+ RAM_SIZE: 8G
+ TROVE_HOST: red-box-v1-trove.example.com
+ TROVE_ID: red-box-v1-trove
+ VCPUS: 2
+ WORKER_SSH_KEY: ssh_keys/worker.key
+ deploy:
+ red-box-v1-controller:
+ type: kvm
+ location: kvm+ssh://vm-user@vm-host/red-box-v1-controller/vm-path/red-box-v1-controller.img
+ DISK_SIZE: 60G
+ DISTBUILD_CONTROLLER: true
+ HOSTNAME: red-box-v1-controller
+ MASON_CLUSTER_MORPHOLOGY: ci.morph
+ MASON_DEFINITIONS_REF: master
+ MASON_DISTBUILD_ARCH: x86_64
+ MASON_TEST_HOST: vm-user@vm-host:/vm-path/
+ MASON_UPSTREAM_TROVE_ADDRESS: upstream-trove
+ WORKERS: red-box-v1-controller
diff --git a/clusters/minimal-system-deploy.morph b/clusters/minimal-system-deploy.morph
new file mode 100644
index 00000000..06629ffc
--- /dev/null
+++ b/clusters/minimal-system-deploy.morph
@@ -0,0 +1,14 @@
+name: minimal-system-deploy
+kind: cluster
+description: |
+ Deploy a minimal system to a system running KVM
+systems:
+- morph: systems/minimal-system-x86_32-generic.morph
+ deploy:
+ vm:
+ type: kvm
+ location: kvm+ssh://192.168.122.1/tiny-x86_32/srv/VMs/tiny-x86_32.img
+ DISK_SIZE: 512M
+ HOSTNAME: tiny-x86_32
+ INIT_SYSTEM: busybox
+ RAM_SIZE: 512M
diff --git a/clusters/release.morph b/clusters/release.morph
new file mode 100644
index 00000000..37defb09
--- /dev/null
+++ b/clusters/release.morph
@@ -0,0 +1,50 @@
+name: release
+kind: cluster
+description: |
+ Deploy all the systems for we support in a release.
+
+ This cluster morph is used by the tool 'scripts/do-release'. While
+ you can deploy the systems yourself, if you are making a Baserock release
+ then the script should be used.
+systems:
+- morph: systems/devel-system-x86_32-chroot.morph
+ deploy:
+ devel-system-x86_32-chroot:
+ type: tar
+ location: devel-system-x86_32-chroot.tar
+- morph: systems/devel-system-x86_32-generic.morph
+ deploy:
+ devel-system-x86_32-generic:
+ type: rawdisk
+ location: devel-system-x86_32-generic.img
+ DISK_SIZE: 4G
+- morph: systems/devel-system-x86_64-chroot.morph
+ deploy:
+ devel-system-x86_64-chroot:
+ type: tar
+ location: devel-system-x86_64-chroot.tar
+- morph: systems/devel-system-x86_64-generic.morph
+ deploy:
+ devel-system-x86_64-generic:
+ type: rawdisk
+ location: devel-system-x86_64-generic.img
+ DISK_SIZE: 4G
+- morph: systems/devel-system-armv7lhf-wandboard.morph
+ deploy:
+ release:
+ type: tar
+ location: devel-system-armv7lhf-wandboard.tar
+- morph: systems/genivi-baseline-system-x86_64-generic.morph
+ deploy:
+ genivi-baseline-system-x86_64-generic:
+ type: rawdisk
+ location: genivi-baseline-system-x86_64-generic.img
+ DISK_SIZE: 4G
+ KERNEL_ARGS: vga=788
+- morph: systems/genivi-baseline-system-armv7lhf-versatile.morph
+ deploy:
+ genivi-baseline-system-armv7lhf-versatile:
+ type: rawdisk
+ location: genivi-baseline-system-armv7lhf-versatile.img
+ DISK_SIZE: 4G
+ KERNEL_ARGS: vga=788
diff --git a/clusters/sdk-example-cluster.morph b/clusters/sdk-example-cluster.morph
new file mode 100644
index 00000000..f71d093d
--- /dev/null
+++ b/clusters/sdk-example-cluster.morph
@@ -0,0 +1,46 @@
+name: sdk
+kind: cluster
+description: |
+ An example of creating a cross-compile SDK for an embedded Baserock system.
+
+ This cluster demonstrates how you can use the 'sdk' write extension to
+ produce a cross-compile SDK tarball for an Baserock applicance. In this
+ example the system is assumed to run on ARMv7, and the SDK is built to
+ run on any x86_32 GNU/Linux system.
+
+ The SDK is a Baserock system itself, containing just 'build-essential' and a
+ 'cross-toolchain' stratum. The SDK system also includes the target
+ appliance's system, as a 'subsystem', so that the libraries and headers are
+ available when building.
+
+ This cluster deploys the SDK system using the 'sdk' write extension, which
+ produces a tarball with a small shell header. When the shell header is
+ executed, and passed a directory name on the commandline, it extracts the SDK
+ to that path and patches the binaries so that they execute correctly from
+ that directory.
+
+ Deploying the applicate system artifact to the target device should be
+ done with a separate cluster morphology, because you will often want to
+ do this without rebuilding the SDK.
+
+ You must build each system with `morph build` before deploying. We recommend
+ doing this all from your Baserock development machine, using a Baserock
+ ARM distributed build network to produce the system artifact. Once both
+ system artifacts are cached locally, the `morph deploy` command will produce
+ a self-extracting shell script/tarball following the 'location' field.
+
+ See the documentation of the sdk.write extension for more information.
+systems:
+- morph: systems/armv7lhf-cross-toolchain-system-x86_32-generic.morph
+ deploy:
+ sdk:
+ type: sdk
+ location: armv7lhf-cross-toolchain-system-x86_32-generic.sh
+ PREFIX: /usr
+ TARGET: armv7lhf-baserock-linux-gnueabi
+ subsystems:
+ - morph: systems/devel-system-armv7lhf-highbank.morph
+ deploy:
+ sysroot:
+ type: sysroot
+ location: usr/armv7lhf-baserock-linux-gnueabi/sys-root
diff --git a/clusters/trove.baserock.org-upgrade.morph b/clusters/trove.baserock.org-upgrade.morph
new file mode 100644
index 00000000..eaf939e1
--- /dev/null
+++ b/clusters/trove.baserock.org-upgrade.morph
@@ -0,0 +1,23 @@
+name: trove.baserock.org-upgrade
+kind: cluster
+description: |
+ This is a cluster morphology for deploying an UPGRADE to
+ git.baserock.org. It doesn't work for the initial deployment. The
+ deployer MUST have ssh access to root@git.baserock.org. To use:
+
+ morph deploy --upgrade trove.baserock.org-upgrade gbo.VERSION_LABEL=2014-05-29
+
+ Replace the value of gbo.VERSION_LABEL above with the current date.
+ You can add letters if you need to upgrade multiple times in a day.
+systems:
+- morph: systems/trove-system-x86_64.morph
+ deploy:
+ gbo:
+ type: ssh-rsync
+ location: root@git.baserock.org
+ FSTAB_HOME: LABEL=homes /home auto defaults,noatime,rw 0 2
+ HOSTNAME: firehose1
+ LORRY_CONTROLLER_MINIONS: 4
+ TROVE_COMPANY: Baserock
+ TROVE_HOSTNAME: git.baserock.org
+ TROVE_ID: baserock
diff --git a/clusters/upgrade-devel.morph b/clusters/upgrade-devel.morph
new file mode 100644
index 00000000..3937521e
--- /dev/null
+++ b/clusters/upgrade-devel.morph
@@ -0,0 +1,39 @@
+name: upgrade-devel
+kind: cluster
+description: |
+ This is a cluster morphology that can be used to deploy systems to a
+ an existing Baserock devel system, as an upgrade of the running system.
+
+ This method is for users who deployed a system manually from one of the
+ images provided on http://download.baserock.org. IT IS ONLY POSSIBLE TO
+ UPGRADE BASEROCK 14 RELEASES OR NEWER.
+
+ If you deployed your system using `morph deploy` then you should reuse the
+ cluster morphology you did the initial deployment with, instead of this one,
+ so that the configuration is preserved in the new system.
+
+ Ensure that your root user has passwordless SSH access to localhost with
+ `ssh root@localhost whoami`. If not, run `ssh-copy-id root@localhost`.
+ Make sure the 'morph' field below matches the system you are upgrading.
+
+ To upgrade, select a sensible a value for VERSION_LABEL and run:
+
+ morph deploy --upgrade upgrade-devel.morph self.HOSTNAME=$(hostname) self.VERSION_LABEL=$VERSION_LABEL
+
+ Your configuration in /etc should be propagated to the new system, but there
+ may be merge conflicts. Check /etc for files named '.rej' and '.orig' in the
+ new system, which will indicate that there are changes from the old system
+ that must be merged manually. You can get a nice diff from the old /etc as
+ follows:
+
+ mount /dev/sda /mnt
+ git diff --no-index /mnt/systems/factory/run/etc /mnt/systems/$VERSION_LABEL/run/etc
+
+ On a base system, use 'diff -r' instead of 'git diff --no-index'. It will
+ not be as colourful.
+systems:
+- morph: systems/devel-system-x86_64-generic.morph
+ deploy:
+ self:
+ type: ssh-rsync
+ location: root@localhost