Revision feec31d1 doc/design-2.3.rst

b/doc/design-2.3.rst
487 487
informationally, not for allocation decisions.
488 488

  
489 489

  
490
Node flags
491
----------
492

  
493
Current state and shortcomings
494
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
495

  
496
Currently all nodes are, from the point of view of their capabilities,
497
homogeneous. This means the cluster considers all nodes capable of
498
becoming master candidates, and of hosting instances.
499

  
500
This prevents some deployment scenarios: e.g. having a Ganeti instance
501
(in another cluster) be just a master candidate, in case all other
502
master candidates go down (but not, of course, host instances), or
503
having a node in a remote location just host instances but not become
504
master, etc.
505

  
506
Proposed changes
507
~~~~~~~~~~~~~~~~
508

  
509
Two new capability flags will be added to the node:
510

  
511
- master_capable, denoting whether the node can become a master
512
  candidate or master
513
- vm_capable, denoting whether the node can host instances
514

  
515
In terms of the other flags, master_capable is a stronger version of
516
"not master candidate", and vm_capable is a stronger version of
517
"drained".
518

  
519
For the master_capable flag, it will affect auto-promotion code and node
520
modifications.
521

  
522
The vm_capable flag will affect the iallocator protocol, capacity
523
calculations, node checks in cluster verify, and will interact in novel
524
ways with locking (unfortunately).
525

  
526
It is envisaged that most nodes will be both vm_capable and
527
master_capable, and just a few will have one of these flags
528
removed. Ganeti itself will allow clearing of both flags, even though
529
this doesn't make much sense currently.
530

  
531

  
490 532
Job priorities
491 533
--------------
492 534

  

Also available in: Unified diff