Commit feec31d1 authored by Iustin Pop's avatar Iustin Pop

Add documentation about the capability flags

Signed-off-by: default avatarIustin Pop <iustin@google.com>
Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
parent e13377bc
......@@ -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
~~~~~~~~
......
......@@ -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
--------------
......
......@@ -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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment