HROLLER(1) Ganeti | Version @GANETI_VERSION@
============================================

NAME
----

hroller \- Cluster rolling maintenance scheduler for Ganeti

SYNOPSIS
--------

**hroller** {backend options...} [algorithm options...] [reporting options...]

**hroller** \--version


Backend options:

{ **-m** *cluster* | **-L[** *path* **]** | **-t** *data-file* |
**-I** *path* }

**[ --force ]**

Algorithm options:

**[ -G *name* ]**

**[ -O *name...* ]**

**[ --node-tags** *tag,..* **]**

Reporting options:

**[ -v... | -q ]**
**[ -S *file* ]**
**[ --one-step-only ]**

DESCRIPTION
-----------

hroller is a cluster maintenance reboot scheduler. It can calculate
which set of nodes can be rebooted at the same time while avoiding
having both primary and secondary nodes being rebooted at the same time.

For backends that support identifying the master node (currenlty
RAPI and LUXI), the master node is scheduled as the last node
in the last reboot group. Apart from this restriction, larger reboot
groups are put first.

ALGORITHM FOR CALCULATING OFFLINE REBOOT GROUPS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

hroller will view the nodes as vertices of an undirected graph,
with two kind of edges. Firstly, there are edges from the primary
to the secondary node of every instance. Secondly, two nodes are connected
by an edge if they are the primary nodes of two instances that have the
same secondary node. It will then color the graph using a few different
heuristics, and return the minimum-size color set found. Node with the same
color can then simultaneously migrate all instance off to their respective
secondary nodes, and it is safe to reboot them simultaneously.

OPTIONS
-------

For a description of the standard options check **htools**\(7) and
**hbal**\(1).

\--node-tags *tag,...*
  Restrict to nodes having at least one of the given tags.

\--one-step-only
  Restrict to the first reboot group. Output the group one node per line.

\--offline-maintenance
  Pretend that all instances are shutdown before the reboots are carried
  out. I.e., only edges from the primary to the secondary node of an instance
  are considered.

\--force
  Do not fail, even if the master node cannot be determined.


BUGS
----

Offline nodes should be ignored.

If instances are online the tool should refuse to do offline rolling
maintenances, unless explicitly requested.

End-to-end shelltests should be provided.

Online rolling maintenances (where instance need not be shut down, but
are migrated from node to node) are not supported yet. Hroller by design
should support them both with and without secondary node replacement.

EXAMPLES
--------

Online Rolling reboots, using tags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Selecting by tags and getting output for one step only can be used for
planing the next maintenance step.
::

   $ hroller --node-tags needsreboot --one-step-only -L
   'First Reboot Group'
    node1.example.com
    node3.example.com

Typically these nodes would be drained and migrated.
::

   $ GROUP=`hroller --node-tags needsreboot --one-step-only --no-headers -L`
   $ for node in $GROUP; do gnt-node modify -D yes $node; done
   $ for node in $GROUP; do gnt-node migrate -f --submit $node; done

After maintenance, the tags would be removed and the nodes undrained.


Offline Rolling node reboot output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If all instances are shut down, usually larger node groups can be found.
::

    $ hroller --offline-maintainance -L
    'Node Reboot Groups'
    node1.example.com,node3.example.com,node5.example.com
    node8.example.com,node6.example.com,node2.example.com
    node7.example.com,node4.example.com

.. vim: set textwidth=72 :
.. Local Variables:
.. mode: rst
.. fill-column: 72
.. End: