| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The openstack.write extension was calling a nonexistent method
'check_location'. This metod was moved to openstack.check
in the commit ba7d1d1ed3bad002ce36e5d4adf4e3794625091a.
|
| |
|
|\
| |
| |
| |
| | |
Reviewed-by: Sam Thursfield
Reviewed-by: Lars Wirzenius
|
| |
| |
| |
| |
| |
| |
| |
| | |
If the credentials are wrong, then morph will fail before
attempting the OpenStack deployment.
To achieve that openstack.check will attempt to run
`glance image-list`.
|
| |
| |
| |
| | |
Found by Richard Maw.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The KVM and VirtualBox deployments use sparse files for raw disk
images. This means they can store a large disk (say, tens or hundreds
of gigabytes) without using more disk space than is required for the
actual content (e.g., a gigabyte or so for the files in the root
filesystem). The kernel and filesystem make the unwritten parts of the
disk image look as if they are filled with zero bytes. This is good.
However, during deployment those sparse files get transferred as if
there really are a lot of zeroes. Those zeroes take a lot of time to
transfer. rsync, for example, does not handle large holes efficiently.
This change introduces a couple of helper tools (morphlib/xfer-hole
and morphlib/recv-hole), which transfer the holes more efficiently.
The xfer-hole program reads a file and outputs records like these:
DATA
123
binary data (exaclyt 123 bytes and no newline at the end)
HOLE
3245
xfer-hole can do this efficiently, without having to read through all
the zeroes in the holes, using the SEEK_DATA and SEEK_HOLE arguments
to lseek.
Using this, the holes take only take a few bytes each, making it
possible to transfer a disk image faster. In my benchmarks,
transferring a 100G byte disk image took about 100 seconds for KVM,
and 220 seconds for VirtualBox (which needs to more work at the
receiver to convert the raw disk to a VDI). Both benchmarks were from
a VM on my laptop to the laptop itself.
The interesting bit here is that the receiver (recv-hole) is simple
enough that it can be implemented in a bit of shell script, and the
text of the shell script can be run on the remote end by giving it to
ssh as a command line argument. This means there is no need to install
any special tools on the receiver, which makes using this improvement
much simpler.
|
|
|
|
|
|
| |
The arguments to `morph deploy` can get quite long, any way we can make it
shorter and clearer is useful. We can also avoid having the strange
--no-upgrade flag in future.
|
|
|
|
|
|
|
|
|
|
| |
This avoids confusion when the user expected to be doing an initial
deployment and wasn't aware that a file with the same name as the
target already existed. Previously rawdisk.write would try to mount
the file and upgrade it.
Now we require the user to pass '--upgrade' when they intend to
upgrade, as with other deployment extensions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If btrfs is not present in the kernel we end up with strange output like
this:
Error creating disk image2014-06-10 16:00:40
[devel-system-x86_64-generic][my-raw-disk-image][rawdisk.write]Failure
to create disk image at /src/tmp/testdev.img
ERROR: Command failed: mount -o loop /src/tmp/testdev.img
/src/tmp/deployments/tmpQ7wXO1/tmp4lVDcu/tmpvHSzDE
mount: mounting /dev/loop0 on
/src/tmp/deployments/tmpQ7wXO1/tmp4lVDcu/tmpvHSzDE failed: Device or
resource busy
To avoid this confusing error, Morph should explicitly check first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If INITRAMFS_PATH is specified and the file exists, then the produced
kernel command line will use root=UUID=$uuid_of_created_disk rather than
root=/dev/sda, which may be incorrect.
Help files have been updated to mention the new option.
This leads to an unfortunate duplication of the path to the initramfs,
in both the location field of the nested deployment and the
INITRAMFS_PATH of the disk image creation.
However, an initramfs could be produced by a chunk and put in the same
place, so it doesn't make sense to couple the rawdisk and initramfs
write extensions to remove this duplication.
Similarly, there may be multiple valid initramfs in the rootfs e.g.
extlinux loads a hypervisor, which is Linux + initramfs, and the
initramfs then boots a guest Linux system, which uses a different
initramfs.
This makes it important to explicitly let the rootfs write extensions
know which to use, or not as the case may be.
util-linux's blkid is required, since the busybox version ignores the
options to filter its output, and parsing the output is undesirable.
Because syslinux's btrfs subvolume support is limited to being able to
use a non-0 default subvolume, the initramfs has to be copied out of
the run-time rootfs subvolume and into the boot subvolume.
This pushed the required disk space of a minimal system over the 512M
threshold because we do not have the userland tooling support to be able
to do a btrfs file contents clone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a gzipped cpio archive that may be used as an initramfs.
It is hard-coded to use gzip to compress the initramfs, since it's the
most common way to do it.
This is unfortunate, since the busybox gzip utility only allows maximum
compression, which is rather slow and doesn't give progress reporting,
so you can easily think it's gotten stuck.
It's possible to use other compression formats, but they need the kernel
to be built with them supported, and in the case of lz4, unusual userland
tools to create it, since the version of lz4 supported in the kernel is
not what the standard lz4 tools produce.
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
Add support to the VirtualBox write extension to notice if we are
doing a Vagrant Basebox installation and not do the clever network
setup we normally do to allow machines to talk to one another since
this confuses Vagrant quite a bit if it is left in.
|
|
|
|
|
| |
Move the help out of the comment and into a help file,
and add a clearer example.
|
| |
|
|
|
|
|
| |
Test that a VM with the given name does not already exist, and check
that the files specified in ATTACH_DISKS do already exist.
|
|
|
|
|
| |
Also, change it to log the real error message in morph.log before
raising a more general exception to the user.
|
|
|
|
|
|
| |
Slight duplication is necessary, but it's only a few lines. We could
move the duplicated code into the base class in 'morphlib.writeexts' if
there was more duplication.
|
|
|
|
|
|
| |
Begin adding help documentation for configuration
and write extensions starting with nfsboot.write,
rawdisk.write and tar.write.
|
| |
|
|
|
|
|
| |
We were building it from a variable in some places and hardcoding it in
others; now we build it from a variable everywhere.
|
|
|
|
|
|
|
|
|
|
|
| |
Move some code to the '.check' extension to verify that the deployment
can happen *before* spending 5 minutes unpacking and configuring the
rootfs.
This is not a perfect solution yet because when multiple systems are
being deployed in a cluster, we do not check all systems and then
deploy them all. Instead, we check one, then deploy it, then check the
second, etc.
|
| |
|
|
|
|
|
|
|
|
|
| |
There is no longer a default /etc/fstab in the Baserock fhs-dirs chunk,
and the nfsboot.write extension does not use the default Btrfs system
layout so no entry is added for / to /etc/fstab at deploy-time.
We cannot have / in /etc/fstab for nfsboot deployments because it
causes systemd to remount / during bootup, which breaks everything.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the deployed system to somewhere on the host.
Any existing contents of the directory is deleted, so don't try to be
clever and deploy a new system on top of / in place of a proper upgrade.
It can be used to deploy a chroot, sysroot or container, but its
current use is to allow for nested deployments to include another
system in itself, since the parent deployment's "$1" is prepended to
the sub-deployment's "$2".
|
|
|
|
|
|
|
| |
If the disk image was not yet created then the os.remove() call fails
and the original exception gets lost, causing confusion and sadness.
Also print status earlier on failure
|
|
|
|
|
| |
Most write extensions don't handle both initial deployments and upgrades
of a system.
|
|
|
|
|
| |
Now you can deploy an upgrade, set it to be the default version and reboot
into it all with one call to `morph deploy`.
|
|
|
|
|
| |
Also, be more flexible when parsing environment booleans -- convert to
lower case and match 0/1 and true/false as well as yes/no.
|
| |
|
|
|
|
|
|
| |
We now have a OS version manager tool in Baserock (in tbdiff.git). The
code to deploy a new base OS version should live there, to minimise
duplication between write extensions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shared state directories defined in writeexts.py (/var, /home etc.)
are now separate Btrfs subvolumes that are mounted in place using fstab.
There are some warnings on mounting /var and /srv about the mountpoint
not being empty. Not yet investigated.
If a configure extension has already added / to the fstab, use the
device it chose rather than assuming /dev/sda. This is required for the
vdaboot.configure extension that we use for OpenStack deployments.
Similarly, if a configure extension has added an entry for a state
directory in /etc/fstab already, we don't replace it with a /state/xxx
directory. That's only done as a default behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
VirtualBox changed a command line option in 4.3 incompatibly, so we now
have to check the version number and change an option from --sataportcount
to --portcount if the version of VirtualBox running on the target is at
least 4.3
This turns the version into a tuple and compares it against another,
since it's more reliable than comparing strings, which will count '1.10'
as earlier than '1.2', and more convenient than comparing the digits
individually.
|
|
|
|
|
|
|
|
|
|
|
| |
This option lets the install-files config extension overwrite existing files.
A file will only be overwritten if the overwrite flag is specified for that file.
Since the overwrite arg is optionally prepended to the manifest line,
this patch should not break existing manifests
With this patch default config files can be replaced with project specific
config files
|
|\ |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Reviewed-by: Richard Maw
At his suggestion, fixed the call to sorted() to be a call
to asciibetical().
|
|/ /
| |
| |
| |
| | |
This will allow the user to append text to /etc/fstab during a
deployment, without having to write custom configuration extensions.
|
|/ |
|
|
|
|
|
| |
This snuck in since the test suite could not be run when TMPDIR was
on a tmpfs.
|
|
|
|
|
|
|
|
|
| |
openstackssh.write: Write extension which deploy a raw image of baserock
directly to an OpenStack machine using python-glanceclient. The raw image
deployed has modified its bootloader to use virtio disks.
vdaboot.configure: Configuration extension to change the mount point of
"/" to use virtio disks (/dev/vda).
|
|
|
|
| |
Patch from Paul Sherwood.
|
| |
|
| |
|
|
|
|
| |
systems.
|