From feec31d16d9f875ce4dc8e59f507cc4470e6b32a Mon Sep 17 00:00:00 2001
From: Iustin Pop <iustin@google.com>
Date: Tue, 26 Oct 2010 13:59:22 +0200
Subject: [PATCH] Add documentation about the capability flags
Signed-off-by: Iustin Pop <iustin@google.com>
Reviewed-by: Michael Hanselmann <hansmi@google.com>
---
doc/admin.rst | 16 ++++++++++++++++
doc/design-2.3.rst | 42 ++++++++++++++++++++++++++++++++++++++++++
man/ganeti.sgml | 33 +++++++++++++++++++++++++++++++++
3 files changed, 91 insertions(+)
diff --git a/doc/admin.rst b/doc/admin.rst
index 1918dbe3b..9e90df859 100644
--- a/doc/admin.rst
+++ b/doc/admin.rst
@@ -78,6 +78,22 @@ Depending on the role, each node will run a set of daemons:
- the :command:`ganeti-masterd` daemon which runs on the master node and
allows control of the cluster
+Beside the node role, there are other node flags that influence its
+behaviour:
+
+- the *master_capable* flag denotes whether the node can ever become a
+ master candidate; setting this to 'no' means that auto-promotion will
+ never make this node a master candidate; this flag can be useful for a
+ remote node that only runs local instances, and having it become a
+ master is impractical due to networking or other constraints
+- the *vm_capable* flag denotes whether the node can host instances or
+ not; for example, one might use a non-vm_capable node just as a master
+ candidate, for configuration backups; setting this flag to no
+ disallows placement of instances of this node, deactivates hypervisor
+ and related checks on it (e.g. bridge checks, LVM check, etc.), and
+ removes it from cluster capacity computations
+
+
Instance
~~~~~~~~
diff --git a/doc/design-2.3.rst b/doc/design-2.3.rst
index aa25f54a8..9392bcf32 100644
--- a/doc/design-2.3.rst
+++ b/doc/design-2.3.rst
@@ -487,6 +487,48 @@ Also note that the node group information is provided just
informationally, not for allocation decisions.
+Node flags
+----------
+
+Current state and shortcomings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Currently all nodes are, from the point of view of their capabilities,
+homogeneous. This means the cluster considers all nodes capable of
+becoming master candidates, and of hosting instances.
+
+This prevents some deployment scenarios: e.g. having a Ganeti instance
+(in another cluster) be just a master candidate, in case all other
+master candidates go down (but not, of course, host instances), or
+having a node in a remote location just host instances but not become
+master, etc.
+
+Proposed changes
+~~~~~~~~~~~~~~~~
+
+Two new capability flags will be added to the node:
+
+- master_capable, denoting whether the node can become a master
+ candidate or master
+- vm_capable, denoting whether the node can host instances
+
+In terms of the other flags, master_capable is a stronger version of
+"not master candidate", and vm_capable is a stronger version of
+"drained".
+
+For the master_capable flag, it will affect auto-promotion code and node
+modifications.
+
+The vm_capable flag will affect the iallocator protocol, capacity
+calculations, node checks in cluster verify, and will interact in novel
+ways with locking (unfortunately).
+
+It is envisaged that most nodes will be both vm_capable and
+master_capable, and just a few will have one of these flags
+removed. Ganeti itself will allow clearing of both flags, even though
+this doesn't make much sense currently.
+
+
Job priorities
--------------
diff --git a/man/ganeti.sgml b/man/ganeti.sgml
index 80b5a922a..3bb4f42ea 100644
--- a/man/ganeti.sgml
+++ b/man/ganeti.sgml
@@ -146,6 +146,39 @@
</para>
</refsect2>
+ <refsect2>
+ <title>Node flags</title>
+
+ <para>Nodes have two flags which govern which roles they can take:
+ <variablelist>
+ <varlistentry>
+ <term>master_capable</term>
+ <listitem>
+ <para>
+ The node can become a master candidate, and
+ furthermore the master node. When this flag is
+ disabled, the node cannot become a candidate; this can
+ be useful for special networking cases, or less
+ reliable hardware.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>vm_capable</term>
+ <listitem>
+ <para>
+ The node can host instances. When enabled (the default
+ state), the node will participate in instance
+ allocation, capacity calculation, etc. When disabled,
+ the node will be skipped in many cluster checks and
+ operations.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </refsect2>
+
<refsect2>
<title>Cluster configuration</title>
--
GitLab