Skip to content
Snippets Groups Projects
Commit 00b66530 authored by Guido Trotter's avatar Guido Trotter
Browse files

design-2.1: Update OS Flavours section


This reflects a discussion we had, according to which the full
"parameters" implementation is too heavy weight for 2.1, and we should
have a partial version for now, and decide again later.

Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
Reviewed-by: default avatarIustin Pop <iustin@google.com>
parent c772d142
No related branches found
No related tags found
No related merge requests found
...@@ -229,8 +229,8 @@ regression as of today, because even if the OSes are left blind about this ...@@ -229,8 +229,8 @@ regression as of today, because even if the OSes are left blind about this
information, sometimes they still need to make compromises and cannot satisfy information, sometimes they still need to make compromises and cannot satisfy
all possible parameter values. all possible parameter values.
OS Parameters OS Flavours
+++++++++++++ +++++++++++
Currently we are assisting to some degree of "os proliferation" just to change Currently we are assisting to some degree of "os proliferation" just to change
a simple installation behavior. This means that the same OS gets installed on a simple installation behavior. This means that the same OS gets installed on
...@@ -249,24 +249,30 @@ deboostrap-etch-server, debootstrap-etch-dev, debootrap-lenny-server, ...@@ -249,24 +249,30 @@ deboostrap-etch-server, debootstrap-etch-dev, debootrap-lenny-server,
debootstrap-lenny-dev, etc. Crossing more than two parameters quickly becomes debootstrap-lenny-dev, etc. Crossing more than two parameters quickly becomes
not manageable. not manageable.
In order to avoid this we plan to make OSes more customizable, by allowing In order to avoid this we plan to make OSes more customizable, by allowing each
arbitrary flags to be passed to them. These will be special "OS parameters" OS to declare a list of flavours which can be used to customize it. The
which will be handled by Ganeti mostly as hypervisor or be parameters. This flavours list is mandatory for new API OSes and must contain at least one
slightly complicates the interface, but allows one OS (for example supported flavour. When choosing the OS exactly one flavour will have to be
"debootstrap" to be customizable and not require copies to perform different specified, and will be encoded in the os name as <OS-name>+<flavour>. As for
cations). today it will be possible to change an instance's OS at creation or install
time.
Each OS will be able to declare which parameters it supports by listing them
one per line in a special "parameters" file in the OS dir. The parameters can The 2.1 OS list will be the combination of each OS, plus its supported
have a per-os cluster default, or be specified at instance creation time. They flavours. This will cause the name name proliferation to remain, but at least
will then be passed to the OS scripts as: INSTANCE_OS_PARAMETER_<NAME> with the internal OS code will be simplified to just parsing the passed flavour,
their specified value. The only value checking that will be performed is that without the need for symlinks or code duplication.
the os parameter value is a string, with only "normal" characters in it.
Also we expect the OSes to declare only "interesting" flavours, but to accept
It will be impossible to change parameters for an instance, except at reinstall some non-declared ones which a user will be able to pass in by overriding the
time. Upon reinstall with a different OS the parameters will be by default checks ganeti does. This will be useful for allowing some variations to be used
discarded and reset to the default (or passed) values, unless a special without polluting the OS list (per-OS documentation should list all supported
--keep-known-os-parameters flag is passed. flavours). If a flavour which is not internally supported is forced through,
the OS scripts should abort.
In the future (post 2.1) we may want to move to full fledged orthogonal
parameters for the OSes. In this case we envision the flavours to be moved
inside of Ganeti and be associated with lists parameter->values associations,
which will then be passed to the OS.
IAllocator changes IAllocator changes
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment