Revision 00b66530
| b/doc/design-2.1.rst | ||
|---|---|---|
| 229 | 229 |
information, sometimes they still need to make compromises and cannot satisfy |
| 230 | 230 |
all possible parameter values. |
| 231 | 231 |
|
| 232 |
OS Parameters
|
|
| 233 |
+++++++++++++
|
|
| 232 |
OS Flavours
|
|
| 233 |
+++++++++++ |
|
| 234 | 234 |
|
| 235 | 235 |
Currently we are assisting to some degree of "os proliferation" just to change |
| 236 | 236 |
a simple installation behavior. This means that the same OS gets installed on |
| ... | ... | |
| 249 | 249 |
debootstrap-lenny-dev, etc. Crossing more than two parameters quickly becomes |
| 250 | 250 |
not manageable. |
| 251 | 251 |
|
| 252 |
In order to avoid this we plan to make OSes more customizable, by allowing |
|
| 253 |
arbitrary flags to be passed to them. These will be special "OS parameters" |
|
| 254 |
which will be handled by Ganeti mostly as hypervisor or be parameters. This |
|
| 255 |
slightly complicates the interface, but allows one OS (for example |
|
| 256 |
"debootstrap" to be customizable and not require copies to perform different |
|
| 257 |
cations). |
|
| 258 |
|
|
| 259 |
Each OS will be able to declare which parameters it supports by listing them |
|
| 260 |
one per line in a special "parameters" file in the OS dir. The parameters can |
|
| 261 |
have a per-os cluster default, or be specified at instance creation time. They |
|
| 262 |
will then be passed to the OS scripts as: INSTANCE_OS_PARAMETER_<NAME> with |
|
| 263 |
their specified value. The only value checking that will be performed is that |
|
| 264 |
the os parameter value is a string, with only "normal" characters in it. |
|
| 265 |
|
|
| 266 |
It will be impossible to change parameters for an instance, except at reinstall |
|
| 267 |
time. Upon reinstall with a different OS the parameters will be by default |
|
| 268 |
discarded and reset to the default (or passed) values, unless a special |
|
| 269 |
--keep-known-os-parameters flag is passed. |
|
| 252 |
In order to avoid this we plan to make OSes more customizable, by allowing each |
|
| 253 |
OS to declare a list of flavours which can be used to customize it. The |
|
| 254 |
flavours list is mandatory for new API OSes and must contain at least one |
|
| 255 |
supported flavour. When choosing the OS exactly one flavour will have to be |
|
| 256 |
specified, and will be encoded in the os name as <OS-name>+<flavour>. As for |
|
| 257 |
today it will be possible to change an instance's OS at creation or install |
|
| 258 |
time. |
|
| 259 |
|
|
| 260 |
The 2.1 OS list will be the combination of each OS, plus its supported |
|
| 261 |
flavours. This will cause the name name proliferation to remain, but at least |
|
| 262 |
the internal OS code will be simplified to just parsing the passed flavour, |
|
| 263 |
without the need for symlinks or code duplication. |
|
| 264 |
|
|
| 265 |
Also we expect the OSes to declare only "interesting" flavours, but to accept |
|
| 266 |
some non-declared ones which a user will be able to pass in by overriding the |
|
| 267 |
checks ganeti does. This will be useful for allowing some variations to be used |
|
| 268 |
without polluting the OS list (per-OS documentation should list all supported |
|
| 269 |
flavours). If a flavour which is not internally supported is forced through, |
|
| 270 |
the OS scripts should abort. |
|
| 271 |
|
|
| 272 |
In the future (post 2.1) we may want to move to full fledged orthogonal |
|
| 273 |
parameters for the OSes. In this case we envision the flavours to be moved |
|
| 274 |
inside of Ganeti and be associated with lists parameter->values associations, |
|
| 275 |
which will then be passed to the OS. |
|
| 270 | 276 |
|
| 271 | 277 |
IAllocator changes |
| 272 | 278 |
~~~~~~~~~~~~~~~~~~ |
Also available in: Unified diff