Commit 3f11e70a authored by Constantinos Venetsanopoulos's avatar Constantinos Venetsanopoulos
Browse files

docs: fixes in the architecture sections

parent 4502bda7
Architecture
============
Overview
^^^^^^^^
snf-image is a Ganeti OS definition. This means that Ganeti provisions a new
disk (block device) and passes it to snf-image. Then, snf-image is responsible
to deploy an Image on that disk. If snf-image returns successfully, Ganeti will
then spawn a VM with that disk as its primary disk.
Thus, snf-image is responsible for two (2) things, which are executed in two
separate steps:
| 1. Fill the newly provisioned disk with Image data
| 2. Customize the Image accordingly
For (1), snf-image can fetch the Image from a number of backends, as we describe
later. For (2) snf-image spawns a helper VM and runs a number of configuration
tasks inside the isolated environment. Once the last task returns successfully,
the helper VM ceases and snf-image returns the newly configured disk to Ganeti.
The whole procedure is configurable via OS interface parameters, that can be
passed to snf-image from the Ganeti command line or RAPI.
snf-image is split in two components: The main program running on the Ganeti
host with full root privilege (*snf-image* previously *snf-image-host*) and a
host with full root privilege (*snf-image*, previously *snf-image-host*) and a
part running inside an unprivileged helper VM (*snf-image-helper*).
We describe each part in the following sections:
snf-image
^^^^^^^^^
This part implements the Ganeti OS interface. It extracts the Image onto the
Ganeti-provided block device, using streaming block I/O (dd with oflag=direct),
then passes control to snf-image-helper running inside a helper VM. The helper
VM is created using KVM, runs as an unprivileged user, nobody by default.
then spawns a helper VM, and passes control to snf-image-helper running inside
that helper VM. The helper VM is created using either KVM or XEN depending on
the supported hypervisor as dictated by Ganeti. It runs as an unprivileged
user.
There is no restriction on the distribution running inside the helper VM, as
long as it executes the snf-image-helper component automatically upon bootup.
The snf-image-update-helper script is provided with snf-image to automate the
creation of a helper VM image based on Debian Stable, using multistrap.
The snf-image-helper component is spawned inside a specific hardware
environment:
The snf-image-helper component runs inside a specific environment, which is
created and ensured by snf-image:
* The VM features a virtual floppy, containing an ext2 filesystem with all
parameters needed for image customization.
* The hard disk of the VM being deployed is accessible as the first virtio
hard disk.
* The hard disk provided by Ganeti that we want to deploy and customize is
accessible as the first virtio hard disk.
* All kernel/console output is redirected to the first virtual serial console,
and eventually finds its way into the OS definition log files that Ganeti
maintains.
* The helper VM is expected to output "SUCCESS" to its second serial port if
image customization was successful inside the VM.
* In any other case, execution of the helper VM or snf-image-helper has
failed.
* If "SUCCESS" is not returned, snf-image assumes that, execution of the helper
VM or snf-image-helper has failed.
* The helper VM is expected to shutdown automatically once it is done. Its
execution is time-limited; if it has not terminated after a number of
seconds, configurable via /etc/default/snf-image, it is sent a SIGTERM
and/or a SIGKILL.
KVM is currently a dependency for snf-image, meaning it is needed to spawn the
helper VM. There is no restriction on the hypervisor used for the actual Ganeti
instances. This is not a strict requirement; KVM could be replaced by qemu,
doing full CPU virtualization without any kernel support for spawning the
helper VM.
seconds, configurable via ``/etc/default/snf-image``, snf-image sends a
SIGTERM and/or a SIGKILL to it.
snf-image-helper
^^^^^^^^^^^^^^^^
This part runs inside the helper VM and undertakes customization of the VM
being deployed using a number of hooks, or tasks. The tasks run in an
environment, specified by rules found in a virtual floppy, placed there by
*snf-image*. *snf-image-helper* uses runparts to run tasks found under
*/usr/lib/snf-image-helper/tasks* by default
This part runs inside the helper VM during bootup and undertakes customization
of the target disk. It does so, by running a number of :ref:`configuration
tasks <image-configuration-tasks>`. The exact tasks that should run, are
specified by rules found in the virtual floppy, placed there by *snf-image*,
before spawning the helper VM. *snf-image-helper* uses *runparts* to run the
tasks which are found under ``/usr/lib/snf-image-helper/tasks``.
Graphical Representation
^^^^^^^^^^^^^^^^^^^^^^^^
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment