Revision 4dfac6af doc/design-2.1.rst
| b/doc/design-2.1.rst | ||
|---|---|---|
| 451 | 451 |
information, sometimes they still need to make compromises and cannot satisfy |
| 452 | 452 |
all possible parameter values. |
| 453 | 453 |
|
| 454 |
OS Flavours
|
|
| 454 |
OS Variants
|
|
| 455 | 455 |
+++++++++++ |
| 456 | 456 |
|
| 457 | 457 |
Currently we are assisting to some degree of "os proliferation" just to change |
| ... | ... | |
| 472 | 472 |
not manageable. |
| 473 | 473 |
|
| 474 | 474 |
In order to avoid this we plan to make OSes more customizable, by allowing each |
| 475 |
OS to declare a list of flavours which can be used to customize it. The |
|
| 476 |
flavours list is mandatory for new API OSes and must contain at least one |
|
| 477 |
supported flavour. When choosing the OS exactly one flavour will have to be |
|
| 478 |
specified, and will be encoded in the os name as <OS-name>+<flavour>. As for |
|
| 475 |
OS to declare a list of variants which can be used to customize it. The |
|
| 476 |
variants list is mandatory and must be written, one variant per line, in the |
|
| 477 |
new "variants.list" file inside the main os dir. At least one supported variant |
|
| 478 |
must be supported. When choosing the OS exactly one variant will have to be |
|
| 479 |
specified, and will be encoded in the os name as <OS-name>+<variant>. As for |
|
| 479 | 480 |
today it will be possible to change an instance's OS at creation or install |
| 480 | 481 |
time. |
| 481 | 482 |
|
| 482 | 483 |
The 2.1 OS list will be the combination of each OS, plus its supported |
| 483 |
flavours. This will cause the name name proliferation to remain, but at least
|
|
| 484 |
the internal OS code will be simplified to just parsing the passed flavour,
|
|
| 484 |
variants. This will cause the name name proliferation to remain, but at least
|
|
| 485 |
the internal OS code will be simplified to just parsing the passed variant,
|
|
| 485 | 486 |
without the need for symlinks or code duplication. |
| 486 | 487 |
|
| 487 |
Also we expect the OSes to declare only "interesting" flavours, but to accept
|
|
| 488 |
Also we expect the OSes to declare only "interesting" variants, but to accept
|
|
| 488 | 489 |
some non-declared ones which a user will be able to pass in by overriding the |
| 489 | 490 |
checks ganeti does. This will be useful for allowing some variations to be used |
| 490 | 491 |
without polluting the OS list (per-OS documentation should list all supported |
| 491 |
flavours). If a flavour which is not internally supported is forced through,
|
|
| 492 |
variants). If a variant which is not internally supported is forced through,
|
|
| 492 | 493 |
the OS scripts should abort. |
| 493 | 494 |
|
| 494 |
In the future (post 2.1) we may want to move to full fledged orthogonal |
|
| 495 |
parameters for the OSes. In this case we envision the flavours to be moved |
|
| 496 |
inside of Ganeti and be associated with lists parameter->values associations, |
|
| 497 |
which will then be passed to the OS. |
|
| 495 |
In the future (post 2.1) we may want to move to full fledged parameters all |
|
| 496 |
orthogonal to each other (for example "architecture" (i386, amd64), "suite" |
|
| 497 |
(lenny, squeeze, ...), etc). (As opposed to the variant, which is a single |
|
| 498 |
parameter, and you need a different variant for all the set of combinations you |
|
| 499 |
want to support). In this case we envision the variants to be moved inside of |
|
| 500 |
Ganeti and be associated with lists parameter->values associations, which will |
|
| 501 |
then be passed to the OS. |
|
| 502 |
|
|
| 498 | 503 |
|
| 499 | 504 |
IAllocator changes |
| 500 | 505 |
~~~~~~~~~~~~~~~~~~ |
Also available in: Unified diff