NAME

       harep - Ganeti auto-repair tool

SYNOPSIS

       harep [ [-L | --luxi ] = socket ] [ --job-delay = seconds ] [ --dry-run ]

       harep --version

DESCRIPTION

       Harep  is the Ganeti auto-repair tool.  It is able to detect that an instance is broken and to generate a
       sequence of jobs that will fix it, in accordance to the  policies  set  by  the  administrator.   At  the
       moment, only repairs for instances using the disk templates plain or drbd are supported.

       Harep  is  able  to  recognize  what  state  an  instance is in (healthy, suspended, needs repair, repair
       disallowed, pending repair, repair failed) and to lead it through a sequence of steps that will bring the
       instance back to the healthy state.  Therefore, harep is mainly meant to be run regularly and  frequently
       using a cron job, so that it can actually follow the instance along all the process.  At every run, harep
       will  update  the  tags  it  adds to instances that describe its repair status, and will submit jobs that
       actually perform the required repair operations.

       By default, harep only reports on the health status of instances, but doesn't perform any action, as they
       might be potentially dangerous.  Therefore, harep will only touch instances that it has  been  explicitly
       authorized to work on.

       The  tags  enabling  harep,  can  be  associated  to  single instances, or to a nodegroup or to the whole
       cluster, therefore affecting all the  instances  they  contain.   The  possible  tags  share  the  common
       structure:

              ganeti:watcher:autorepair:<type>

       where <type> can have the following values:

       • fix-storage:  allow  disk  replacement or fix the backend without affecting the instance itself (broken
         DRBD secondary)

       • migrate: allow instance migration.  Note, however, that current harep does not submit migrate jobs; so,
         currently, this permission level is equivalent to fix-storage.

       • failover: allow instance reboot on the secondary; this action is taken, if the primary node is offline.

       • reinstall: allow disks to be recreated and the instance to be reinstalled

       Each element in the list of tags, includes all the authorizations of the previous one,  with  fix-storage
       being the least powerful and reinstall being the most powerful.

       In case multiple autorepair tags act on the same instance, only one can actually be active.  The conflict
       is solved according to the following rules:

       1. if multiple tags are in the same object, the least destructive takes precedence.

       2. if the tags are across objects, the nearest tag wins.

       Example:  A  cluster  has  instances  I1  and I2, where I1 has the failover tag, and the cluster has both
       fix-storage and reinstall.  The I1 instance will  be  allowed  to  failover,  the  I2  instance  only  to
       fix-storage.

LIMITATIONS

       Harep doesn't do any hardware failure detection on its own, it relies on nodes being marked as offline by
       the administrator.

       Also harep currently works only for instances with the drbd and plain disk templates.

       Using  the  data  model  of  htools(1),  harep  cannot distinguish between drained and offline nodes.  In
       particular, it will (permission provided) failover instances also in situations where a  migration  would
       have  been  enough.   In  particular,  handling of node draining is better done using hbal(1), which will
       always submit migration jobs, however is the permission to fall back to failover.

       These issues will be addressed by a  new  maintenance  daemon  in  future  Ganeti  versions,  which  will
       supersede harep.

OPTIONS

       The options that can be passed to the program are as follows:

       -L socket, --luxi=*socket*
              collect data via Luxi, optionally using the given socket path.

       --job-delay=*seconds*
              insert  this  much  delay  before  the  execution  of  repair  jobs  to allow the tool to continue
              processing instances.

       --dry-run
              only show which operations would be carried out, but do nothing,  even  on  instances  where  tags
              grant  the  appropriate  permissions.   Note  that  harep  keeps the state of repair operations in
              instance tags; therefore, only the operations of the next round of actions can be inspected.

REPORTING BUGS

       Report bugs to the project's issue tracker or contact the developers using the Ganeti mailing list.

SEE ALSO

       Ganeti overview and  specifications:  ganeti(7)  (general  overview),  ganeti-os-interface(7)  (guest  OS
       definitions), ganeti-extstorage-interface(7) (external storage providers).

       Ganeti  commands:  gnt-cluster(8) (cluster-wide commands), gnt-job(8) (job-related commands), gnt-node(8)
       (node-related  commands),  gnt-instance(8)  (instance   commands),   gnt-os(8)   (guest   OS   commands),
       gnt-storage(8)   (storage   commands),   gnt-group(8)  (node  group  commands),  gnt-backup(8)  (instance
       import/export commands), gnt-debug(8) (debug commands).

       Ganeti daemons: ganeti-watcher(8) (automatic instance restarter), ganeti-cleaner(8) (job queue  cleaner),
       ganeti-noded(8) (node daemon), ganeti-rapi(8) (remote API daemon).

       Ganeti  htools: htools(1) (generic binary), hbal(1) (cluster balancer), hspace(1) (capacity calculation),
       hail(1) (IAllocator plugin), hscan(1) (data gatherer from remote clusters), hinfo(1) (cluster information
       printer), mon-collector(7) (data collectors interface).

COPYRIGHT

       Copyright (C) 2006-2015 Google Inc.  All rights reserved.

       Redistribution and use in source and binary forms, with or without modification, are  permitted  provided
       that the following conditions are met:

       1.   Redistributions  of  source code must retain the above copyright notice, this list of conditions and
       the following disclaimer.

       2.  Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
       the following disclaimer in the documentation and/or other materials provided with the distribution.

       THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY  EXPRESS  OR  IMPLIED
       WARRANTIES,  INCLUDING,  BUT  NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
       PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE  FOR
       ANY  DIRECT,  INDIRECT,  INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
       LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS
       INTERRUPTION)  HOWEVER  CAUSED  AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
       TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE  OF  THIS  SOFTWARE,  EVEN  IF
       ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Ganeti                                                                                                  HAREP(1)