Rename, in the design, the repair daemon to maintenance daemon.
This better reflects the role of this daemon as, besides repairs,
it will also take care of other maintenance operations, like
balancing.
Signed-off-by: Klaus Aehlig <[email protected]>
---
doc/design-repaird.rst | 44 +++++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/doc/design-repaird.rst b/doc/design-repaird.rst
index 3cb6bd8..bd91cc0 100644
--- a/doc/design-repaird.rst
+++ b/doc/design-repaird.rst
@@ -1,11 +1,13 @@
-====================
-Ganeti Repair Daemon
-====================
+=========================
+Ganeti Maintenance Daemon
+=========================
.. contents:: :depth: 4
This design document outlines the implementation of a new Ganeti
-daemon coordinating repairs on a cluster.
+daemon coordinating all maintenance operations on a cluster
+(rebalancing, activate disks, ERROR_down handling, node-repair
+actions).
Current state and shortcomings
@@ -32,7 +34,7 @@ swap.
Proposed changes
================
-We propose the addition of an additional daemon, called ``repaird`` that will
+We propose the addition of an additional daemon, called ``maintd`` that will
coordinate the work for repair needs of individual nodes. The information
about the work to be done will be obtained from a dedicated data collector
via the :doc:`design-monitoring-agent`.
@@ -70,7 +72,7 @@ attempting live migrations, respectively.
details
.......
-An opaque JSON value that the repair daemon will just pass through and
+An opaque JSON value that the maintenance daemon will just pass through and
export. It is intended to contain information about the type of repair
that needs to be done after the respective Ganeti action is finished.
E.g., it might contain information which piece of hardware is to be
@@ -99,7 +101,7 @@ directory will be ``/etc/ganeti/node-diagnose-commands``.
Result forging
..............
-As the repair daemon will take real Ganeti actions based on the diagnose
+As the maintenance daemon will take real Ganeti actions based on the diagnose
reported by the self-diagnose script through the monitoring daemon, we
need to verify integrity of such reports to avoid denial-of-service by
fraudaulent error reports. Therefore, the monitoring daemon will sign
@@ -117,27 +119,27 @@ being requested) for this event and forget about it, as
soon as it is
no longer observed.
Corresponding Ganeti actions will be initiated and success or failure of
-these Ganeti jobs monitored. All jobs submitted by the repair daemon
-will have the string ``gnt:daemon:repaird`` and the event identifier
+these Ganeti jobs monitored. All jobs submitted by the maintenance daemon
+will have the string ``gnt:daemon:maintd`` and the event identifier
in the reason trail, so that :doc:`design-optables` is possible.
Once a job fails, no further jobs will be submitted for this event
to avoid further damage; the repair action is considered failed in this case.
Once all requested actions succeeded, or one failed, the node where the
-event as observed will be tagged by a tag starting with
``repaird:repairready:``
-or ``repaird:repairfailed:``, respectively, where the event identifier is
+event as observed will be tagged by a tag starting with
``maintdd:repairready:``
+or ``maintd:repairfailed:``, respectively, where the event identifier is
encoded in the rest of the tag. On the one hand, it can be used as an
additional verification whether a node is ready for a specific repair.
However, the main purpose is to provide a simple and uniform interface
-to acknowledge an event; once that tag is removed, the repair daemon
+to acknowledge an event; once that tag is removed, the maintenance daemon
will forget about this event, as soon as it is no longer observed by
any monitoring daemon.
-Repair daemon
--------------
+Maintenance daemon
+------------------
-The new daemon ``repaird`` will be running on the master node only. It will
+The new daemon ``maintd`` will be running on the master node only. It will
verify the master status of its node by popular vote in the same way as all the
other master-only daemons. If started on a non-master node, it will exit
immediately with exit code ``exitNotmaster``, i.e., 11.
@@ -180,7 +182,7 @@ as a JSON object with at least the following information.
is still observed.
+ ``failed`` At least one of the submitted jobs has failed. To avoid further
- damage, the repair daemon will not take any further action for this event.
+ damage, the maintenance daemon will not take any further action for this
event.
+ ``completed`` All Ganeti actions associated with this event have been
completed successfully, including tagging the node.
@@ -195,7 +197,7 @@ State
~~~~~
As repairs, especially those involving physically swapping hardware, can take
-a long time, the repair daemon needs to store its state persistently. As we
+a long time, the maintenance daemon needs to store its state persistently. As
we
cannot exclude master-failovers during a repair cycle, it does so by storing
it as part of the Ganeti configuration.
@@ -205,9 +207,9 @@ The SSConf will not be changed.
Superseeding ``harep`` and implicit balancing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To have a single point coordinating all repair actions, the new repair daemon
+To have a single point coordinating all repair actions, the new daemon
will also have the ability to take over the work currently done by ``harep``.
-To allow a smooth transition, ``repaird`` when carrying out ``harep``'s duties
+To allow a smooth transition, ``maintd`` when carrying out ``harep``'s duties
will add tags in precisely the same way as ``harep`` does.
As the new daemon will have to move instances, it will also have the ability
to balance the cluster in a way coordinated with the necessary evacuation
@@ -222,7 +224,7 @@ continue to exist unchanged as part of the ``htools``.
Mode of operation
~~~~~~~~~~~~~~~~~
-The repair daemon will at fixed interval poll the monitoring daemons for
+The maintenance daemon will at fixed interval poll the monitoring daemons for
the value of the self-diagnose data collector; if load-based balancing is
enabled, it will also collect for the the load data needed.
@@ -232,7 +234,7 @@ A new round will be started if all jobs of the old round
have finished, and
there is an unhandled repair event or the cluster is unbalanced enough (provided
that autobalancing is enabled).
-In each round, ``repaird`` will first determine the most invasive action for
+In each round, ``maintd`` will first determine the most invasive action for
each node; despite the self-diagnose collector summing observations in a single
action recommendation, a new, more invasive recommendation can be issued before
the handling of the first recommendation is finished. For all nodes to be
--
2.4.3.573.g4eafbef
