Synnefo » snf-ganeti

These scripts receive through environment variables a fixed set of parameters

following changes.

OS parameters categories

++++++++++++++++++++++++

Change the OS parameters to have three categories:

* ``public``: the current behavior. The parameter is logged and stored freely.

* ``private``: the parameter is saved inside the Ganeti configuration (to allow

  for instance reinstall) but it is not shown in logs, job logs, or passed back

  via RAPI.

* ``secret``: the parameter is not saved inside the Ganeti configuration.

  Reinstalls are impossible unless the data is passed again. The parameter will

  not appear in any log file. When a functionality is performed jointly by

  multiple daemons (such as MasterD and LuxiD), currently Ganeti sometimes

  serializes jobs on disk and later reloads them. Secret parameters will not be

  serialized to disk. They will be passed around as part of the LUXI calls

  exchanged by the daemons, and only kept in memory, in order to reduce their

  accessibility as much as possible. In case of failure of the master node,

  these parameters will be lost and cannot be recovered because they are not

  serialized. As a result, the job cannot be taken over by the new master.  This

  is an expected and accepted side effect of jobs with secret parameters: if

  they fail, they'll have to be restarted manually.

Metadata

++++++++

In order to allow metadata to be sent inside the instance, a communication

mechanism between the instance and the host will be created.  This mechanism

will be bidirectional (e.g.: to allow the setup process going on inside the

instance to communicate its progress to the host). Each instance will have

access exclusively to its own metadata, and it will be only able to communicate

with its host over this channel.  This is the approach followed the

``cloud-init`` tool and more details will be provided in the `Communication

mechanism and metadata service`_ section.

Installation procedure

++++++++++++++++++++++

A new installation procedure will be introduced, with which it will be possible

to use an installation medium and run the OS scripts in an optional virtualized

environment and with an optional personalization package.  There will be two

sets of parameters, namely, installation parameters, which are used mainly for

installs and reinstalls, and execution parameters, which are used in all the

other runs that are not part of an installation procedure.

This set of installation parameters will allow, e.g., to attach an installation

floppy/cdrom/network, change the boot device order, or specify a disk image to

be used.  Through this set of parameters, the administrator will have to provide

the hypervisor a location for an installation medium for the instance (e.g., a

boot disk, a network image, etc).  This medium will carry out the installation

of the instance onto the instance's disks and will then be responsible for

getting the parameters for configuring the instance, such as, network

interfaces, IP address, and hostname.  These parameters are taken from the

metadata.  The installation parameters will be stored in the configuration of

Ganeti and used in future reinstalls, but not during normal execution.

The instance is reinstalled using the same installation parameters from the

first installation.  However, it will be the administrator's responsibility to

ensure that the any installation media is still available at the proper location

when a reinstall occurs.

The parameter ``--os-parameters`` can still be used to specify the OS

parameters.  However, without OS scripts, Ganeti cannot do more than a syntactic

check to validate the supplied OS parameters string.  As a result, this string

will be directly passed to the instance as part of the metadata.  If the

installation procedure is running inside a virtualized environment, then Ganeti

will take these parameters from the metadata and pass them to the OS scripts as

environment variables.

* Use a disk image:

  Currently, it is already possible to specify an installation medium, such as,

  a cdrom, but not a disk image.  Therefore, a new parameter ``--os-image`` will

  be used to specify the location of a disk image which will be dumped to the

  instance's first disk before the instance is started.  The location of the

  image can be a URL and, if this is the case, Ganeti will download this image.

* Run OS scripts:

  The parameter ``--os-type`` (short version: ``-o``), is currently used to

  specify the OS scripts.  This parameter will still be used to specify the OS

  scripts with the difference that these OS scripts may optionally run inside a

  virtualized environment for safety reasons, depending on whether they are

  trusted or not.  For more details on trusted and untrusted OS scripts, refer

  to the `Installation process in a virtualized environment`_ section.

* Personalization package

  As part of the instance creation command, it will be possible to indicate a

  URL for a "personalization package", which is an archive containing a set of

  files meant to be overlayed on top of the OS file system at the end of the

  setup process and before the VM is started for the first time in normal mode.

  Ganeti will provide a mechanism for receiving and unpacking this archive

  whether the installation is being performed inside the virtualized environment

  or not.

  The archive will be in TAR-GZIP format (with extension ``.tar.gz`` or

  ``.tgz``) and contain the files according to the directory structure that will

  be recreated on the installation disk.  Files contained in this archive will

  overwrite files with the same path created during the installation procedure

  (if any).  The URL of the "personalization package" will have to specify an

  extension to identify the file format (in order to allow for more formats to

  be supported in the future).  The URL will be stored as part of the

  configuration of the instance (therefore, the URL should not contain

  confidential information, but the files there available can).

  It is up to the system administrator to ensure that a package is actually

  available at that URL at install and reinstall time.  The contents of the

  package are allowed to change.  E.g.: a system administrator might create a

  package containing the private keys of the instance being created.  When the

  instance is reinstalled, a new package with new keys can be made available

  there, thus allowing instance reinstall without the need to store keys.  A

  username and a password can be specified together with the URL.  If the URL is

  a HTTP(S) URL, they will be used as basic access authentication credentials to

  access that URL.  The username and password will not be saved in the config,

  and will have to be provided again in case a reinstall is requested.

  The downloaded personalization package will not be stored locally on the node

  for longer than it is needed while unpacking it and adding its files to the

  instance being created.  The personalization package will be overlayed on top

  of the instance filesystem after the scripts that created it have been

  executed.  In order for the files in the package to be automatically overlayed

  on top of the instance filesystem, it is required that the appliance is

  actually able to mount the instance's disks.  As a result, this will not work

  for every filesystem.

* Combine a disk image, OS scripts, and a personalization package

  It will possible to combine a disk image, OS scripts, and a personalization

  package, both with or without a virtualized environment.  There is one

  exception which is if there are untrusted OS scripts.  At least, an

  installation medium or OS scripts should be specified.

  The disk image of the actual virtual appliance, which bootstraps the virtual

  environment used in the installation procedure, will be read only, so that a

  pristine copy of the appliance can be started every time a new instance needs

  to be created and to further increase security.  The data the instance needs

  to write at runtime will only be stored in RAM and disappear as soon as the

  instance is stopped.

  The parameter ``--enable-safe-install=yes|no`` will be used to give the

  administrator control over whether to use a virtualized environment for the

  installation procedure.  By default, a virtualized environment will be used.

  Note that some feature combinations, such as, using untrusted scripts, will

  require the virtualized environment.  In this case, Ganeti will not allow

  disabling the virtualized environment.

#. Instance creation via a disk image

#. Instance creation inside a virtualized environment

because they are deeply tied. The communication mechanism will be made more

generic because it can be used for other purposes in the future (like allowing

instances to explicitly send commands to Ganeti, or to let Ganeti control a

helper instance, like the one hereby introduced for performing OS installs

inside a safe environment).

The communication mechanism will be enabled automatically during an installation

procedure that requires a virtualized environment, but for backwards

compatibility it will be disabled when the instance is running normally, unless

it is explicitly requested. Specifically, a new parameter

``--communication=yes|no`` (short version: ``-C``) will be added to

instance has a communication channel set to interact with the host and receive

metadata. The value of this parameter will be saved as part of the configuration

of the instance.

The installation scripts to be run inside the virtualized environment will be

available at::

  http://169.254.169.254/ganeti/<version>/os/scripts/<script_name>