Revision 4dfac6af

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