[PATCH 0/3] Changes to Trove required for upgrades
by Sam Thursfield
Repo: git://git.baserock.org/baserock/baserock/definitions
Ref: baserock/sam/trove-upgrades
Sha1: f18ee7fcf02a000dd487a8381d7b02ae4c2e0167
Sam Thursfield (3):
trove: Avoid running trove-early-setup on upgrades
trove: Don't keep trove-early-setup systemd unit in /var
trove: Make dependency graph of trove-early-setup.service clearer
trove.configure | 43 +++++++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 10 deletions(-)
--
1.8.4
9 years
[PATCH 00/13] V3: Changes to Morph required for upgrades
by Sam Thursfield
Repo: git://git.baserock.org/baserock/baserock/morph.git
Ref: upgrades-v3
Sha1: ba722fc08d0a3a59a169a4e3a125ab416b94363b
The major change in V3 is that configure extensions now run when
deploying upgrades. If you need an extension to behave differently when
deploying an upgrade (this is the case for trove.configure for example,
as we only want trove-early-setup to run once within the lifetime of a
Trove) you can check `if [ "$UPGRADE" == "yes" ]` or similar in the
extension.
Note that the upgrades are deployed client-side using the
system-version-manager tool, so any system you are deploying as an
upgrade needs to contain that tool.
The following two changes I did not have time to do, but would like to do in
the future:
- report progress and status from 'system-version-manager' and
'baserock-system-config-sync' when deploying an upgrade.
- move the checks that we are deploying to a valid target into .check
extensions, so that a bad `morph deploy` will fail earlier.
- split .upgrade extensions out from .write
- tidy up yarns/deployment.yarn
As before, branch was tested using the system tests in
git://git.baserock.org/baserock/baserock/system-tests, which build the
baserock/sam/trove-upgrades system branch right now. (Next step is to merge the
contents of that system branch).
Pedro Alvarez (1):
Adding syslinux 'menu.c32' file during the deployment.
Sam Thursfield (12):
deploy: Add new --upgrade option
deploy: Finish off the Btrfs system layout implementation
Don't create a blank /etc/fstab
deploy: Depend on client OS version manager to deploy upgrades
deploy: Honour AUTOSTART in ssh-rsync extension
Make parse_autostart() into more general get_environment_boolean()
deploy: Add optional 'check' extensions
deploy: Check the --upgrade flag has been used correctly.
deploy: Fix double exception in rawdisk.write
deploy: Add upgrading to deployment.yarn
yarns: Set PYTHONPATH when running Morph
morphlib/builder2.py | 25 ---
morphlib/cachekeycomputer.py | 2 +-
morphlib/exts/kvm.check | 35 ++++
morphlib/exts/kvm.write | 4 +-
morphlib/exts/nfsboot.check | 34 ++++
morphlib/exts/openstack.check | 35 ++++
morphlib/exts/rawdisk.write | 7 +-
morphlib/exts/ssh-rsync.check | 36 ++++
morphlib/exts/ssh-rsync.write | 142 ++++++----------
morphlib/exts/tar.check | 24 +++
morphlib/exts/virtualbox-ssh.check | 35 ++++
morphlib/exts/virtualbox-ssh.write | 2 +-
morphlib/plugins/deploy_plugin.py | 29 +++-
morphlib/writeexts.py | 204 +++++++++++++++++------
tests.as-root/tarball-image-is-sensible.stdout | 1 -
tests.build/bootstrap-mode.stdout | 1 -
tests.build/build-stratum-with-submodules.stdout | 1 -
tests.build/build-system.stdout | 1 -
yarns/deployment.yarn | 30 +++-
yarns/implementations.yarn | 10 ++
yarns/morph.shell-lib | 2 +-
21 files changed, 480 insertions(+), 180 deletions(-)
create mode 100755 morphlib/exts/kvm.check
create mode 100755 morphlib/exts/nfsboot.check
create mode 100755 morphlib/exts/openstack.check
create mode 100755 morphlib/exts/ssh-rsync.check
create mode 100755 morphlib/exts/tar.check
create mode 100755 morphlib/exts/virtualbox-ssh.check
--
1.8.5.3
9 years
[PATCH] Proof of concept cross compiling system morphology
by Richard Maw
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10442/cross-toolchain
SHA1: f8a37cd9aab241e3bba872a7da5ee35867ce4e4a
Land: origin/master
This is a system that contains a cross compiler to build for armv7lhf.
It currently works, though there's a couple of changes I'd like to try
to make the morphologies simpler.
It has a few architectural pit-falls, that I'd like to fix some day:
* The sysroot requires the version of eglibc to be exactly the same as
the one we aim to build binaries for, so until there's some way of
pinning the two to the same thing, it's a social problem to keep them
at the same version.
* A bunch of other software needs to be cross-compiled to usefully target
the final system for full application development. These also need to
be pinned to exactly the same version, or include a development variant
of the target system at /usr/armv7lhf-baserock-linux-gnueabi/sys-root,
so the included gcc can find all the libraries and headers.
If it were possible to include this system at build-time, then the
cross-compiler stratum would trivially be just the gcc and binutils
targetting that sysroot and compiled to have the right --host and
--target set.
* It's a bunch of repeated work to cross-compile to various architectures,
some form of parameterised stratum morphologies would make this easier.
Richard Maw (1):
Add morphologies for armv7lhf cross system
...lhf-cross-toolchain-system-x86_64-generic.morph | 15 +++++++++
armv7lhf-cross-toolchain.morph | 37 ++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 armv7lhf-cross-toolchain-system-x86_64-generic.morph
create mode 100644 armv7lhf-cross-toolchain.morph
--
1.8.5.rc2
9 years